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Foreword 

This Technical Specification (TS) has been produced by ETSI Project Broadband Radio Access Networks (BRAN). 

The present document is part 2 of a multi-part deliverable covering the Broadband Radio Access Networks (BRAN); 
HIPERLAN Type 2; Data Link Control (DEC) Layer, as identified below: 

Part 1: "Basic Data Transport Functions"; 

Part 2: "Radio Link Control (RLC) sublayer"; 

Part 3: "Profile for Business Environment"; 

Part 4: "Extension for Home Environment"; 

Part 5: "Profile for Home Environment". 



Introduction 

HIPERLAN type 2 (HIPERLAN/2) is confined to the two lowest layers of the open systems interconnection (OSI) 
model, the physical and the data link control layer. TR 101 683 [20] contains an overall description of the 
HIPERLAN/2 system. The physical layer is described in TS 101 475 [4]. The interworking with higher layers is 
handled by convergence layers on top of the data link control layer. The Packet based Convergence Layer is described 
in TS 101 493 ([17], [18] and [19]) and the Cell based Convergence Layer in TS 101 763 ([15] and [16]). 
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Scope 



The present document specifies the basic Radio Link Control (RLC) sublayer of HIPERLAN/2. The RLC sublayer is 
used to control radio association, resources and connection. 

The present document does not address the requirements and technical characteristics for conformance testing. 
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3 Definitions, symbols and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

Access Point (AP): device that is responsible for the centralized control of the resources in a radio cell 

NOTE: It is usually connected to a fixed network. 

association: process where an MT gets a MAC-ID from an AP 

NOTE: A Dedicated Control CHannel (DCCH) is established. Basic link layer parameters are agreed on between 
an MT and an AP. Encryption start up and authentication are done, if the use of them is decided on for 
this association. Information between convergence layers in the MT and the AP may be transferred. 

Association Control Function (ACF): group of control functions that use the services of the RLC 
These functions are responsible for the handling of the association between MT and AP. 

Association control CHannel (ASCH): logical channel in the uplink that conveys new association request messages 

authentication: corroboration that a peer entity in an association is the one claimed 

Broadcast CHannel (BCH): transport channel that broadcasts control information 

Broadcast Control CHannel (BCCH): logical channel that broadcasts control information which is relevant for the 
current MAC frame 

broadcast frame: MAC frame sent at regular intervals, wherein all MTs in a cell are listening, sleeping ones included 

broadcast phase: part of a MAC Frame in which the AP sends pure control signalling which can be received by any 

MT in the range of the AP 

The Broadcast phase consists of Broadcast Control Channel, Frame Control Channel and Access Feedback CHannel. 

Central Controller (CC): provides control functionality equivalent to that of an access point but is not necessarily 
attached to a fixed network 

NOTE: This term is normally used if central controller and MT functionality are located in a single device. It 
mostly involves direct mode communication. 
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Centralized Mode (CM): in centralized mode, all data transmitted or received by a mobile terminal shall pass the 
access point or the centralized controller, even if the data exchange is between mobile terminals associated to the same 
access point or centralized controller 

DLC connection: HIPERLAN/2 DLC operates connection oriented 

A DLC connection carries user or control data and is identified by a DLC connection identifier. A connection has a set 

of properties for the transfer of data agreed upon between the MT and the AP or between MTs and a CC. 

DLC User Connection (DUC): DLC user connection is uniquely identified by the DLC connection ID and a MAC -ID 

DLC User Connection Control (DUCC): group of control functions that uses the services of the RLC 

It is responsible for the handling of DLC user connections. 

DLCTS:SeeTS 101761-1 [5]. 

Direct Mode (DM): data exchange between MTs associated with the same AP or CC takes place without passing but 
under control of the access point or the central controller 

direct link phase: part of a MAC frame that only contains the data exchanged directly between MTs using direct mode 
communication methods 

downlink phase: part of the Downlink transmission of a MAC Frame during which user and control data is transmitted 
from the access point or central controller to mobile terminals 

NOTE: The data transmitted can be user as well as control data in unicast, broadcast and multicast modes. 

Encryption Function (EF): function that is responsible for keeping user data and part of RLC signalling secret 
between HIPERLAN/2 devices 

Error Control (EC): error control is responsible for detection of transmission errors and, where appropriate, for the 
correction of errors 

Forward-Handover: handover where MT may not inform the old AP/APT about its intention to change to another 
AP/APT 

Frame CHannel (FCH): transport channel that is broadcast and which carries the frame control channel 

Frame Control CHannel (FCCH): logical channel that contains the information defining how the resources are 
allocated in the current MAC frame 

NOTE: Its content changes in general dynamically from frame to frame. 

logical channel: generic term for any distinct data path 

A set of logical channel types is defined for different kinds of data transfer services. Each logical channel type is 
defined by the type of information it carries. Logical channels can be considered to operate between logical connection 
end points. 

MAC frame: periodical structure in time that appears on the air interface and that determines the communication of 
HIPERLAN/2 devices 

Mobile Terminal (MT): device that communicates with an access point or with each other via a radio link 

NOTE: It is typically a user terminal. 
multicast: function that makes it possible for a group of MTs associated to an AP to receive the same information 
PHY mode: PHY mode corresponds to a signal constellation (Modulation alphabet) and a code rate combination 
radio cell: radio cell is the area covered by an access point or central controller 

NOTE: It is sometimes used as a term to describe an AP or CC and its associated terminals. 

Radio Link Control sublayer: control plane of the DLC which offers transport services for the radio resource control, 
association control function and the DLC user connection control 

Radio Resource Control (RRC): group of control functions that use the services of the RLC 
It controls the handling of radio resources. 
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Random Access CHannel (RACH): logical channel in the uplink of the MAC frame in which the MTs can send 
signalling data for the DLC or the RLC 

NOTE: It is transported in the random channel. 

Random access Feedback CHannel (RFCH): logical channel where the result of the access attempts to the random 
channel made in the previous MAC frame is conveyed 

Random CHannel (RCH): transport channel in the uplink of the MAC that carries the logical channels random access 
channel and association control channel 

NOTE: A contention scheme is applied to access it. 
random access phase: period of the MAC Frame where any MT can try to access the system 

NOTE: The access to this phase is based on a contention scheme. 

Resource Grant: allocation of transmission resources by an access point or a central controller 

Resource Request: message from a terminal to an access point or central controller in which the current buffer status is 
conveyed to request for transmission opportunities in the uplink or direct link phase 

sector antenna: term is used to describe if an access point or central controller uses one or more antenna element 

transport channel: basic element to construct PDU trains 
Transport channel describes the message format. 

uplink phase: part of the MAC frame in which data is transmitted from mobile terminals to an access point or a central 
controller 

3.2 Symbols 

For the purposes of the present document, the following symbols apply: 

RxBoW Receivers BoW 

TxBoW Transmitters BoW 

I concatenation of parameters 

3.3 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

ACE Association Control Function 

ACH Access feedback CHannel 

AP ID Access Point IDentifier 

AP Access Point 

APC Access Point Controller 

APT Access Point Transceiver 

ARP Antenna Reference Point 

ARQ Automatic Repeat Request 

ASCH Association control CHannel 

BCCH Broadcast Control CHannel 

BCH Broadcast CHannel 

CC Central Controller 

CL Convergence Layer 

CM Centralized Mode 

DCC DLC user Connection Control 

DCCH Dedicated Control CHannel 

DES Data Encryption Standard 

DFS Dynamic Frequency Selection 

DiL Direct Link 

DL DownLink 
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DLC Data Link Control 

DM Direct Mode 

DUC DLC User Connection 

DUC DLC User Connection 

DUCC DLC User Connection Control 

EC Error Control 

EF Encryption Handover 

FCA Fixed Capacity Agreement 

FCCH Frame Control CHannel 

FCH Frame CHannel 

FSA Fixed Slot Allocation 

HE Home Extension 

HL Higher Layer 

HL/2 HIPERLAN type 2 

HMAC Hash based Message Authentication Code 

HMSC High level MSC 

IV Initialization Vector 

LCH Long transport CHannel 

MAC ID MAC IDentifier 

MAC Medium Access Control 

MD5 Message Digest #5 

MSB Most Significant Bit 

MSC Message Sequence Chart 

MT Mobile Terminal 

NAI Network Access Identifier 

NET ID NET work IDentifier 

NOP ID Network OPerator IDentifier 

NW NetWork 

OAP Optional in the AP 

OMT Optional in the MT 

PDU Protocol Data Unit 

PHY PHYsical layer 

PR PResent 

RACH Random Access CHannel 

RBCH RLC Broadcast CHannel 

RCH Random CHannel 

RFCH Random access Feedback CHannel 

RLC Radio Link Control 

RRC Radio Resource Control 

RSS Received Signal Strength 

SAP Service Access Point 

SCH Short transport CHannel 

SSK Session Secret Key 

UL UpLink 

UOA Use Omni Antenna 
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Overview 



The present document describes the basic RLC functions for the Association, Radio Resource Control and DLC User 
Connection Control between HIPERLAN/2 devices. It consists of functions and message formats for the AP and MT 
side. An overview of HIPERLAN/2 is given in TR 101 683 [20] and detailed description of the DLC basic transport 
functions is given in TS 101 761-1 [5]. It is recommended that TR 101 683 [20] and TS 101 761-1 [5] have been read 
before reading the present document. 



4.1 



BRAN HIPERLAN/2 Protocol Stack 



The HIPERLAN/2 basic protocol stack on the AP side and its functions are shown in figure 1 . It consists of the PHY 
layer on the bottom, the DLC layer in the middle (including RLC sublayer) and one or more convergence layers on top. 
The scope of HIPERLAN/2 standard end at the upper end of the CL on top of which higher layers are located. 



Control Plane 



User Plane 



One instance per MAC-ID 



One instance per AP 

(if several transceivers (APIs) 

per AP, one instance per APT 



Higher Layers 



Convergence Layer 



DLC Control SAP 



DLC User SAP 



Radio Linl< Control sublayer 




Data Linl< Control - 

Basic Data Transport Function 



Error Control 



Medium Access Control 



Physical Layer 



Scope of 

HIPERLAN/2 

standards 



Figure 1 : BRAN HIPERLAN/2 protocol stack in the AP/CC 

The HIPERLAN/2 basic protocol stack on the MT side and its functions are depicted in figure 2. The difference to the 
model of the AP is that it contains only one RLC entity. 
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Control Plane 



User Plane 



One instance per MAC ID 



Higher Layers 
CL SAPs 



Convergence Layer 
DLC Control SAP DLC User SAP 



Radio Llni< Control sublayer 




Data Link Control - 

Basic Data Transport Function 



Error Control 



Medium Access Control 



Physical Layer 



Scope of 

HIPERLAN/2 

standards 



Figure 2: BRAN HIPERLAN/2 protocol stack in the MT 

The present document is confined to the definition of the highhghted part shaded in grey, the RLC sublayer. It describes 
mainly the RLC messages and their format. 

4.2 Functional Entities of RLC sublayer 

The division of functional entities of RLC sublayer is informative. From the perspective of functionality they have been 
divided to four groups in the present document: 

Association Control; 

Radio Resource Control; 

DLC User Connection Control; 

Basic RLC transport machine. 

The Association Control contains the functionality and the messages that are needed for establishing and releasing 
association, including Key Management and Authentication. Additionally, the broadcast and multicast group join and 
leave functions are included in Association Control. 

The Radio Resource Control contains the functionality and the messages of Dynamic Frequency Selection, 
Transmission Power Control, different kind of Handovers, Power Saving, MT_Alive and MT_Absence functions. The 
DLC User Connection Control contains the functionality and the messages of connection Setup, Modify, Reset and 
Release between AP/CC and MT (centralized mode) and between MTs (direct mode). 

4.3 Usage of DLC logical and transport channels 
for RLC messages 

The logical and transport channels of HIPERLAN/2 are described in TS 101 761-1 [5]. The uplink and downlink RLC 
messages use the logical channels DCCH or RBCH. DCCH and RBCH use the transport channels SCH or LCH for 
downlink communication. The logical channel DCCH use the transport channels SCH, LCH or RCH for uplink 
communication. 
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4.4 Transfer Syntax of RLC 



The transfer syntax of the RLC PDUs is described in annex A. The usage of the first octet in all SCH PDUs and the 
three most significant bits of octet three in Uplink SCHs are described in TS 101 761-1 [5]. The first octet and the four 
most significant bits in octet two of the LCH PDUs are defined in TS 101 761-1 [5]. The Most Significant Bit (MSB) is 
always on the left end of the field and therefore not shown separately in the tables in the annex. 

If a parameter is longer than one octet but is contained within one PDU, the most significant bit shall be placed in the 
octet with the lowest octet number of the octets containing the parameter and in the bit with the highest bit number. The 
least significant bit shall be placed in the octet with the highest octet number of the octets containing the parameter and 
in the bit with the lowest bit number. 

If a parameter is longer than one PDU, the most significant bit shall be placed in the PDU that is sent first and follow 
the rules given above with the exception that it is the least significant bit of the first part of the parameter that takes the 
place of the least significant bit of the whole parameter. The first and subsequent PDUs except the last one are 
completely filled. The least significant bit of the parameter shall be placed in the PDU that is sent last and follow the 
rule given above with the exception that it is the most significant bit of the last part of the parameter that takes the place 
of the most significant part. 

Table 1 : Transfer syntax format of the RLC SCH in Downlink 





8 1 7 6 


1 5 1 4 1 3 1 2 


1 


Octet 1 


Oefin^cf in DLC TS '" 




Octet 2 


MSB 


RLC SCH PDU type 




Octet 3 


MSB EXTENSION-TYPE 


|MSB RLC DATA 




Octet 4 


MSB 


RLC DATA 






Octet 7 



Table 2: Transfer syntax format of the RLC SCH in UpLink and RCH 





8 1 7 1 6 


1 5 1 4 1 3 


1 2 1 1 


Octet 1 


Defined in DLC TS 


Octet 2 


MSB 


RLC SCH PDU type 




Octet 3 


Defined in DLC TS 


|MSB EXTENSION-TYPE 


|MSB RLC DATA 


Octet 4 


MSB 


RLC DATA 






Octet 6 


Octet 7 


MAC ID 



Table 3: Transfer syntax format of the RLC LCH in Uplink and Downlink 





8 


7 


6 1 


5 1 4 1 3 1 2 


1 1 


Octet 1 


Defined in 


DLCTS 


MSB 


Sequence number 




Octet 2 




Sequence number 


|MSB EXTENSION-TYPE 


Future use 


Octet 3 


MSB 




RLC LCH PDU type 




Octet 4 


MSB 




RLC DATA 








Octet 51 
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4.5 Sequencing of RLC messages 

The high level MSCs, MSCs and the SDL diagrams define the sequences of the RLC messages. 

The basic principle of sequencing shall be that a new message from a node shall be sent after that a reply to the last 
message has been received. 

An important exception from the basic sequencing rule shall be the following: retransmission of the same message may 
be done in two ways. One way shall be according to the basic rule. The second way shall be that the (same) message is 
transmitted several times without waiting for a reply between the retransmission occasions. 

For timer values that are longer than shortest timer value, an extra reply message shall be used supervised by an extra 
timer with the shortest timer value. The reason for this method is minimize the retransmission time. 

4.6 Message Sequence Charts of RLC 

The Message Sequence Charts (MSCs) of RLC PDU exchanges are shown in the corresponding clauses. Only the 
normal behaviour is defined in the MSCs. 

An MSC consists of messages being exchanged between peers of the system. The messages contain parameters that are 
defined by ASN.L The parts that are used in the RLC MSCs are RLC and environment instances in the MT and also 
RLC and environment instances in the AP. The environment is usually one of the informative function groups ACF, 
RRC or DUC, but may also be something else. 

4.7 Abstract Syntax Notation one of the RLC PDUs 

The mandatory and optional fields of the RLC PDUs are described with Abstract Syntax Notation one (ASN.l). The 
description is in annex B. 

4.8 The text style of RLC PDUs and parameters 

The RLC PDUs are always written with capital letters and an underscore between the words. They are normally called 

messages. 

EXAMPLE 1: RLC_MAC_ID_ASSIGN, RLC_LINK_CAPABILITY_ACK. 

The parameters of RLC PDUs (messages) are written with small italic letters and there is a slash (-) between the words. 

EXAMPLE 2: duc-ext-ind, sleep-interval. 

When an abbreviation, which is also used as a parameter is mentioned in text, the format of abbreviation is used (not the 
format of parameters). 

EXAMPLE 3: MAC ID, AP ID. 

The message exchanges that belong to one function are often called procedures. The functions and procedures are 
written in the following way: the first letter is a capital letter and the rest are small letters. 

EXAMPLE 4: Association, MT_Alive. 
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4.9 Mandatory and Optional functions 

The present document contains mandatory and optional functions at different levels. For functions that are stated as 
mandatory, optional and mandatory subfunctions, messages and parameters can be defined. 

Functions, subfunctions, messages and parameters that are stated as optional in the present document may be set as 
mandatory in extension documents or other documents referring to the present document. 

Every function, subfunction, message or parameter that is optional to implement in order to comply with the present 
document is marked with an "OAP" or "OMT" in the present document, depending on whether it is optional in the MT 
or the AP. All functions, subfunctions, messages and parameters that are not marked are mandatory to implement. 

Functions, subfunctions, messages and parameters that can be selected or not at a particular occasion are negotiated at 
that occasion and the negotiation is specified in the present document in MSCs, ASN.ls, and SDLs. 

EXAMPLE: The Encryption startup PDUs are mandatory to implement, but optional to use. The decision of the 
use is made by the AP. 

4.1 IVIessage transmission not allowed 

It shall not be allowed to send messages to an AP that has set the traffic load indicator in the BCCH to the value 001. 



5 RLC Services 

5.1 Services supporting ACF (Association Control Function) 
5.1.1 Association 

During the Association procedure, the AP allocates a locally unique MAC ID [5] for the requesting MT. 
The Association procedure consists of the following procedures: 

- RBCH Association; 

- MAC ID Assignment; 
Link Capability Negotiation; 

- Encryption Startup; 
Authentication; 

- DM Common Key Distribution (OMT/OAP); 
Info Transfer. 

The order of the procedures is shown in the following high level Message Sequence Chart. 
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MSC Association 



1(11 



MT DISASSOCIATED FROM AP 



RBCH Association 



RBCHAssociation 
_Request 



MAC_ld_Assignment 



LinkCapability 



EncryptionStartup 



Authentication 



S 



DM_Common_Key_ 
Distribution 



Info Transfer 



MT ASSOCIATED TO AP 



Diagram 1 : HMSC of the Association procedure 
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5.1.1.1 



RBCH Association 



The AP shall send the RLC_RBCH_ASSOCIATION message periodically. The number of frames between periodic 
transmission is outside the scope of the standard. The AP shall send the RLC_RBCH_ASSOCIATION message, when 
requested by the MT with RLC_RBCH_ASSOCIATION_REQ message. The MT shall request the 
RLC_RBCH_ ASSOCIATION message, if the MT has not received the periodically sent message. 

If the c-u-g in the RLC_RBCH_ASSOCIATION message indicates that the group is closed, the MT should compare the 
Network Operator ID (NOP ID) to the preferred NOP IDs in the MT before the MT sends RLC_MAC_ID_ASSIGN 
message. The MT should associate to a group that is included in the MT's NOP ID list. If the c-u-g of the AP indicates 
an open group the MT may continue the Association procedure, but the MT shall compare the profile id/version first. 

NOTE: The allocation of the global part of the NOP ID is managed by ETSI. The allocation of the local part of 
the NOP ID is outside of scope of the present document. The network may be set up without having a 
NOP ID for APs. 

If none of the profile id:s/profile versions sent in the RLC_RBCH_ASSOCIATION message is supported by the MT, it 
shall not continue the Association. If one or more of the profile id:s/profile versions sent in the 
RLC_RBCH_ASSOCIATION message is supported by the MT, it may continue the Association. 

Among parameters that are included in the profile id/version is convergence layer id/version. 

If the MT decides to continue the association procedure, the MT shall send the RLC_MAC_ID_ASSIGN message to 
the AP. 



MSC RBCH_Association 

MT ENV 



MT RLC 



AP RLC 



AP ENV 



MT disassociated from AP 



ACF rbch association ind 



(/\CF-RBCH-ASSOCIATION-ARGi) 



(A(^ 



RLC RBCH ASSOCIATION 



{networl<-operator-id, 
profile-vid-list} 



ACFrbchassociationreq 
-RBCH-ASSOCIATION-ARG) 



RLC RBCH ASSOCIATION received 



Diagram 2: RBCH Association 



£75/ 



21 



ETSI TS 101 761-2 VI .3.1 (2002-01) 



MSC RBCH_Association_Request 



( ACF-RBCp-ASSOCIATION-REQ-A^G 

T_rbch_association_req 



ACF_rbch_associatiom"eq_req 



[ ap-id, 
net- id, 
mac- id 9 



ACF_rbch_association_ind 



ACF-^BCH-ASSOCIATION-ARG ) 



Check 
N 2twork_operator_ID 



RLC_RBCH_ASSOCIATION_REQ 



RLC_RBCH_ ASSOCIATION 



{ ne (work-operator- id, 

profile- vid-list) ) 



ACF_rbch_associationreq_ind 



ACF-RBCH-ASSOCIATION-REQ-A^G 



ACF_rbch_association_req 



ACF-OIBCH-ASSOCIATION-ARG ) 



Network_Operator_ID_and_CLID_received 



Diagram 3: RBCH Association Request 



Table 4: RLC-RBCH-ASSOCIATION 



RLC-RBCH-ASSOCIATION-ARG ::= SEQUENCE 



ric-pdu-type 
network-operator-id 
profile-vid-list 



RLC-LCH-PDU-TYPE 
NETWORK-OPERATOR-ID OPTIONAL 
PROFILE-VID-LIST} 



Table 5: RLC-RBCH-ASSOCIATION-REQ (OMT) 



RLC-RBCH-ASSOCIATION-REO-ARG ::= SEQUENCE ■ 



rIc-pdu-type 
ap-id 
net-id 
mac-id 



RLC-SCH-PDU-TYPE 

AP-ID 

NET-ID 

MAC-IDO } 
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5.1.1.2 



MAC ID Assignment 



The MT shall request a MAC ID from the AP by sending RLC_MAC_ID_ASS1GN message. The parameter magic is a 
temporary identifier for the MT and should be a random number. The parameters mac-id and mac-idl of the 
RLC_MAC_1D_ASSIGN message shall be set to zero. The parameter mac-id of the RLC_MAC_ID_ASSIGN_ACK 
message shall contain the MAC ID allocated by the AP. The RLC_MAC_ID_ASSIGN_ACK message shall be sent via 
RBCH. 

NOTE: The mac-id in RLC_MAC_ID_ASSIGN_ACK is doubled to decrease the risk of errors in the mac-id. 

If the AP does not allocate a MAC ID for the MT, the AP shall send the RLC_MAC_ID_ASSIGN_NACK message. 



MSC MACJd_Assignment 



MT ENV 



MT_RLC 



AP_RLC 



AP ENV 



RLC RBCH ASSOCIATION Received 



( {magic, 
ric-version, 
mac-id} 



ACF_macJd_assign_req 



T_macjd_assign 



ACF_macJd_assign_cnf 



Open RLC 
DLCC 



{magic, 
mac-id} 



RLC MAC ID ASSIGN 



( {magic, 
ric-version, 
mac-id 0} 



FiLC_MACJD_ASSIGN_ACK 



( {magic, 

mac-id, 

mac-id1} 



ACF_mac_id_assignJnd 



{magic, 
ric-version, 
mac-id} ) 



ACF_macJd_assign_rsp 



(magic, 
T_macjd_assign_acl< mac-id} 



mac-id repeated for 
safety reasons 



Open RLC 
DLCC 



MAC_ID_Assigned 



Diagram 4: MAC ID Assignment 



Table 6: RLC-MAC-ID-ASSIGN 



RLC-MAC-ID-ASSIGN-ARG ::= SEQUENCE 



ric-pdu-type 
magic 
ric-version 
mac-id 



RLC-SCH-PDU-TYPE 
IVIAGIC 

RLC-VERSION 
IVIAG-IDO } 



Table?: RLC-MAC-ID-ASSIGN-ACK 



RLC-IVIAC-ID-ASSIGN-AGK-ARG ::= SEQUENCE { 



ric-pdu-type 


RLC-SCH-PDU-TYPE 


magic 


MAGIC 


mac-id 


MAC-ID 


mac-id1 


MAC-ID } 



Tables: RLC-MAC-ID-ASSIGN-NACK 



RLC-MAC-ID-ASSIGN-ACK-ARG ::= SEQUENCE { 



ric-pdu-type RLC-SCH-PDU-TYPE 
magic MAGIC} 
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5.1.1.3 



Link Capability 



The MT shall propose Unk capability alternatives to the AP in the RLC_LINK_CAP ABILITY message. The AP shall 
select from the link capability alternatives proposed by the MT and add its own link capabilities to the 
RLC_LINK_CAPABILITY_ACK message, which shall then be sent to the MT. 

If the MT accepts the parameters in the RLC_LINK_CAPABILITY_ACK message, it shall proceed with the 
Association. Whether the Association continues with Encryption startup. Authentication, DM Common Key 
distribution. Info Transfer or goes directly to the associated state, shall be controlled by parameters in the 
RLC_LINK_CAPABILITY_ACK message. 



MSC Link_Capability 



MACJD_AssigiKd 



ACFlinkcapabilityreq 



ACF-LINK-CAPABILITY-ARG 
T_link_capability 



ACFlinkcapabilitycnf 



ACF-LINK-CAPABILITY-ACK-ARG 



RLC_LINK_CAP ABILITY 


T_mac_id_as s ign_ack 
ACF_link_capability_ind 


( {profile-vid-list, 
freq-band, 
rss-value, 
support64qam, 
direct-mode-cap, 
eye lie -pre fix, 
support-fca, 
support-fsa, 
time-gap-ac h- u p link, 
ho-cap, 
cc-ho-cap, 
duty-cycle, 
arq-delay-rx, 
arq-delay-tx, 

authentication-encrypt io n- list, 
dm-attributes } ) 

RLC_LINK_CAPABILITY_ACK 


ACF-LINK-CAPABILITY-ARG 

ACF_link_capability_rsp 


ACF-LINK-CAPABILITY-ACK-ARG 

*#^ T_link_capability_ack 


( (profile-vid-list, 

freq-band, 

rss-value, 

apt-address- length, 

support64qam, 

dm-use-common-key, 

direct-mode-cap, 

cyclic-prefix, 

support-fca, 

support-fea, 

cc-ho-cap, 

arq-delay-rx, 

arq-delay-tx, 

auth-encr-selected, 

dm-attributes, } ) 



Link_Agreed 



Diagram 5: Link Capability Negotiation 



£75/ 



24 



ETSI TS 101 761-2 VI .3.1 (2002-01) 



Table 9: RLC-LINK-CAPABILITY 



RLC-LINK-CAPABILITY-ARG ::= 


SEQUENCE! 


ric-pdu-type 


RLC-LCH-PDU-TYPE 


profile-vid-list 


PROFILE-VID-LIST 


freq-band 


FREQUENCY-BAND 


rss-value 


RSS-VALUE 


support64QAM 


SUPPQRTED64QAM 


direct-mode-cap 


DIRECT-MQDE-CAP 


cyclic-prefix 


CYCLIC-PREFIX 


support-fca 


SUPPQRTED-FCA 


support-fsa 


SUPPQRTED-FSA 


time-gap-ach-uplink 


TIME-GAP-ACH-UPLINK 


ho-cap 


HQ-CAP 


cc-ho-cap 


CC-HO-CAP 


duty-cycle 


DUTY-CYCLE 


arq-delay-rx 


ARQ-DELAY 


arq-delay-tx 


ARQ-DELAY 


authentication-encryption-list 


AUTHENTICATION-ENCRYPTION-LIST 


dm-attributes 


DM-ATTRIBUTES OPTIONAL } 



Table 10: RLC-LINK-CAPABILITY-ACK 



RLC-LINK-CAPABILITY-ACK-ARG ::= SEQUENCE { 


ric-pdu-type 


RLC-LCH-PDU-TYPE 


profiie-vid-iist-selected 


PROFILE-VID-LIST 


freq-band 


FREQUENCY-BAND 


rss-value 


RSS-VALUE 


apt-address-iength 


APT-ADDRESS-LENGTH 


support64QAM 


SUPPORTED64QAM 


dm-use-common-key 


DM-USE-COMMON-KEY 


direct-mode-cap 


DIRECT-MODE-CAP 


cyclic-prefix 


CYCLIC-PREFIX 


support-fca 


SUPPQRTED-FCA 


support-fsa 


SUPPQRTED-FSA 


cc-ho-cap 


CC-HO-CAP 


arq-deiay-rx 


ARQ-DELAY 


arq-deiay-tx 


ARQ-DELAY 


auth-encr-seiected 


AUTH-ENCR-iNFO 


dm-attributes 


DM-ATTRIBUTES OPTIONAL } 
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5.1.1.4 



Encryption startup 



The MT shall calculate and send its public Diffie-Hellman value to the AP. The AP shall also calculate and send its 
public Diffie-Hellman value to the MT. Both MT and AP shall calculate encryption keys based on the received public 
Diffie-Hellman values. How the public Diffie-Hellman values and the encryption keys shall be calculated is described 
in clause 5.1.2.5.1. 



MSC Encryption_Startup 



MT ENV 



MT RLC 



AP RLC 



AP ENV 



LJnk_agreed 



ACF_key_exchange_mt_req 



(ACF-KEY-EXCHANGE-MT-ARG 



T_key_exchange mt 



ACF_key_exchange_ap_cnf 



{ ACF-KEY-EXCHANGE-AP-ARG) 



^LG KEY EXCHANGE MT 1 



({mt-dh-public-value-1} ) 
RLC KEY EXCHANGE MT 2 



({mt-dh-public-value-2} 



T Iink_capabili1y_ack 
ACF_key_exchange_mt_ind 



(ACF-KEY-EXCHANGE-MT-ARG ) 
ACF_key_exchange_ap_rsp 



RLC KEY EXCHANGE AP 1 ( ACF-KEY-EXCHANGE-AP-ARG) 



( {ap-dh-publb-value-1}) 
RLC KEY EXCHANGE AP 2 



T_key_exchange_ap 



( {ap-dh- pubic -value -2}) 



Encryption_ac1ive 



Diagram 6: Encryption Startup procedure 



Table 11 : RLC-KEY-EXCHANGE-l\flT-1 



RLC-KEY-EXCHANGE-MT-1-ARG ::= SEQUENCE { 



ric-pdu-type RLC-LCH-PDU-TYPE 
mt-dh-public-value-1 DH-PUBLIC-VALUE-HALF} 



Table 12: RLC-KEY-EXCHANGE-MT-2 



RLC-KEY-EXCHANGE-MT-2-ARG ::= SEQUENCE { 



rIc-pdu-type 
mt-dh-public-value-2 



RLC-LCH-PDU-TYPE 
DH-PUBLIC-VALUE-HALF } 



Table 13: RLC-KEY-EXCHANGE-AP-1 



RLC-KEY-EXCHANGE-AP-1-ARG ::= SEQUENCE { 



rIc-pdu-type 
ap-dh-public-value-1 



RLC-LCH-PDU-TYPE 
DH-PUBLIC-VALUE-HALF } 
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Table 14: RLC-KEY-EXCHANGE-AP-2 



RLC-KEY-EXCHANGE-AP-2-ARG ::= SEQUENCE { 



ric-pdu-type 
ap-dh-public-value-2 



RLC-LCH-PDU-TYPE 
DH-PUBLIC-VALUE-HALF } 



5.1.1.5 



Authentication 



5.1.1.5.1 



General 



The scope for the authentication is Hmited to the local HIPERLAN/2 wireless LAN. Higher level or remote 
authentication, for example user authentication through the Internet to corporate network, is outside the scope of the 
present document. 

Mutual authentication is supported. MX authentication controls the access of the MX to the connected fixed network. If 
the authentication of the MX fails no access shall be granted to the MX. 

NOXE: AP authentication helps a MX to detect false APs. 

Xhe AP shall decide if MXs are allowed to access the network without authentication, and the MX may decide to cancel 
the access attempt to a network if AP authentication fails or is not supported. 



5.1.1.5.2 



Authentication procedures 



Xhere are six possible types of identifiers for the authentication key, the signalling related to these are shown in the 
HMSC for authentication. 

Xhere are two different types of authentication protocols, pre-shared key based and RS A signature based, 
see clause 5.1.2.6.2. 



MSC Authentication 



1(1) 




Diagram 7: HMSC of the Authentication procedure 
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5.1.1.5.3 



Authentication key identifier alternatives 



5.1.1.5.3.1 



General 



The MT can fetch the authentication key of the AP based on all or parts of the Network Operator (NOP ID), network 
(NET ID), and AP (AP ID) identities that are sent over the broadcast channels. 

Each MT shall be assigned an authentication key identifier that should be presented to the connected AP at association. 
The AP shall use it to retrieve the key related to the access. The identifier can be of different types. One of the identifier 
types is mandatory to implement (free to choose), the remaining ones are optional. The MT authentication key identifier 
should be protected by encryption during transfer to the AP. 



5.1.1.5.3.2 



IEEE address as authentication key identifier (Conditional OAP/OMT, see 
clause 5.1.1.5.3.1) 



This procedure shall use the 48-bit IEEE address [8] as authentication key identifier. The AP shall send a challenge to 
the MT as response. 



MSC AuthenticationJEEE 

MT ENV 



MT RLC 



AP RLC 



AP ENV 



Encryption_active 





ACF_auth_mt_req 


RLC_AUTHENTICATION 


^< T_key_exchange_ap 
^\ T_link_capability_ack 

ACF_auth_mt_ind 






(ACF-AUTHENTICATION-ARG ) 






T_authentication 
ACF_auth_mt_c 


nf 


({moreO, 

mt-auth-id-type ieee, 
mt-auth-icl-content{ieee}} ) 

RLC_AUTHENTICATION_MT 






(ACF-AUTHENTICATION-ARG ) 

ACF_auth_mt_rsp 






( ACF-AUTHENTICATION-MT-ARG) 
/\ T_authentication_mt 






( challenge-to-mt) 




( 


ACF-AUTHENTICATION-MT-ARG) 





Chal lenge_To_MT_Received 



Diagram 8: Authentication IEEE 



Table 15: RLC-AUTHENTICATION 



RLC-AUTHENTICATION-ARG ::= SEQUENCE { 



ric-pdu-type 
more 

mt-auth-id-type 
mt-auth-id-content 



RLC-LCH_PDU-TYPE 
MORE-AUTH 
MT-AUTH-ID-TYPE 
MT-AUTH-CONTENT } 
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Table 16: RLC-AUTHENTICATION-MT 



RLC-AUTHENTICATION-MT-ARG ::= SEQUENCE { 



ric-pdu-type 
challenge-to-mt 



RLC-LCH-PDU-TYPE 
CHALLENGE } 



5.1.1.5.3.3 



Extended IEEE address as authentication key identifier (Conditional OAP/OMT, see 
clause 5.1.1.5.3.1) 



This procedure shall use the 64 bit extended IEEE address [9] as authentication key identifier. The AP shall send a 
challenge to the MT as response. 



MSC Authentication ext IEEE 



MT ENV 



MT RLC 



AP RLC 



AP ENV 



Encryption_active 



ACF_auth_mt_req 



(ACF-AUTHENTICATION-ARG ) 



RLC AUTHENTICATION 



({more 0, 

mt-auth-id-type ext-ieee, 
mt-auth-id-content {ext-ieee}} 



T authentication 



( 
RLC AUTHENTICATION MT 



( {challenge-to-mt}) 



ACF autJn mt cnf 



( ACF-AUTHENTICATION-MT-ARG) 



--X. T_key_exchange_ap 
—X T_link_capability_ack 

ACF auth mt ind 



(ACF-AUTHENTICATION-ARG 



ACF_auth_mt_rsp 



ACF-AUTHENTICATDN-MT-ARG) 
T authentication mt 



Chal lenge_To_MT_Received 



Diagram 9: Authentication EXTJEEE 
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5.1 .1 .5.3.4 Network access identifier as authentication key identifier (Conditional OAP/OMT, 

see clause 5.1.1.5.3.1) 

This procedure shall be used when the NAI (network access identifier) [10] is used as authentication key identifier. The 
AP shall send a challenge to the MT as response. 



MSC Authentication_Net_Acc_ld 

MT ENV I MT RLC 



AP RLC 



AP ENV 



Encryption_active 



ACF_auth_mt_req 



( ACF-AUT HENT ICATION -ARG 



alt 



mt auth id > 46 octets 



mt auth id <= 46 octets 



T authentication 



ACF autti mt cnf 



( ACF-AUTHENTICATI0N-MT-AR(3) 



RLC AUTHENTICATION 



({more 1, 

mt-auth- id-type net-acc-id, 

mt-auth- id-content {net-acc-id}} 

RLC AUTHENTICATION 



({moreO, 

mt-auth- id- type net-acc-id, 

mt-auth-id-content {net-acc-id}} 

RLC AUTHENTICATION 



({more 0, 

mt-auth- id-type net-acc-id, 

mt-auth-id-content {net-acc-id}} 



RLC AUTHENTICATION MT 



( {challenge-to-mt}) 



—X. T_key_exchange_ap 
-^ T_link_capability_ack 

ACF auth mt ind 



(ACF-AUTHENTICATION-ARG 



ACF_auth_mt_rsp 



( ACF-AUTHENTICATION-MT-ARG) 



T authentication mt 



Challenge_To_MT_Received 



Diagram 10: Authentication NAI 
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5.1 .1 .5.3.5 Distinguished name as on authentication key identifier (Conditional OAP/OMT, see 

clause 5.1.1.5.3.1) 

This procedure shall be used if distinguished name [11] is the MT authentication key identifier. The AP shall send a 
challenge to the MT as response. 



MSC Authentication_dist_name 



Encr)ption_active 



ACF_auth_mt_ieq 



({mac -id, 

mt-auth-id-type dsmame, 
mt-auth-id {dst-namej} ) 



T_au then tic ation 



ACF_ailh_mt_ind 



({mac -id, 

mt-auth-id-type dist-4iame, 
mt-auth-id {dist-name } } ) 



ACF_auth_mt_rfp 



( {mac -id, 

challenge- lo-mt}) 



R]jC_AUTHeJTICATION_MT 



T_aulhentical iai_mt 



( {challenge- to-mt 



1)^ 



ACF_auth_mt_cnf 



( {mac- id, 

challenge-to-mt}) 



Challen^_To_Mr_Received 



alt J 






RLC.AUTHENTICATION 


— \/ T key exchai^e ap 
— V^ T link c^abihty ack 


1 
1 




ml_aLlh_id > 46 octets \ 


({mere 1, 

mt-auth-id-t>pe disl-name, 
mt-auUi-id-corlent (dia-name}} ) 

RLC.AUTHENTICATION. 2 










({mo-eO, 

mt-auth-id-type dist-name, 
mt-auth-id-coilent (did -name}] ) 










RLC.AUTHENTICATION 


-X 


T_key_exchai^e_ap 
T_link_capabilily_ack 


1 




mt_auth_id <= 46 octets \ 


({mo-eO, 

mt-auth-id-t>pe dist-name, 
mt-aulh-id-coilent [did -name}) ) 









Diagram 11: Authentication Distinguished name 
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5.1.1.5.3.6 



Compressed type as authentication key identifier (Conditional OAP/OMT, see 
clause 5.1.1.5.3.1) 



This procedure shall be used if the compressed type is the MT authentication key identifier. The compressed type can 
be used if the available authentication key identifier is so long that it is not possible to carry in the defined RLC 
messages. The compressed authentication key identifier is calculated as follows: 

compressed-authentication-key-identifier = MD5(available_authentication_key_identifier). The AP shall send a 
challenge to the MT as response. 



MSC Authentication_Com pressed 



MT ENV 



MT RLC 



AP RLC 



AP ENV 



ACF_auth_mt_req 



(ACF-AUTHENTICATION-ARG 



Encryptionactive 



RLC AUTHENTICATION 



({more 0, 

mt-auth-id-type compressed, 

mt-auth-id-content {compressed}} 



T authentication 



RLC AUTHENTICATION MT 



challenge-to-mt) 



ACF auth mt cnf 



ACF-AUTHENTICATION-MT-ARG) 



—X. T_key_exchange_ap 
—X T_link_capability_ack 

ACF auth mt ind 



(ACF-AUTHENTICATION-ARG 



ACF_auth_mt_rsp 



( ACF-AUTHENTICATION-MT-ARG) 



T authentication mt 



Ch all eng e_To_M T_R ece ived 



Diagram 12: Authentication Compressed 
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5.1.1.5.3.7 



Generic type as authentication key identifier (Conditional OAP/OMT, see 
clause 5.1.1.5.3.1) 



This procedure shall be used if the generic type is the MT authentication key identifier. The generic type is a non- 
structured octet string. The AP shall send a challenge to the MT as response. 

MSC Authentication Generic 



MT ENV 



MT RLC 



AP RLC 



AP ENV 



Encrypt ion_active 



ACF_auth_mt_req 



(ACF-AUTHENTICATION-ARG ) 



alt 



mt_auth_id longer than 46 octets fil-C_AUTHENTICATION 



mt_auth_id up to 46 octets 



T authentication 



ACF auth mt cnf 



( ACF-AUTHENTICATION-MT-ARG) 



({niore 1, 

mt-auth-id-lype generic, 
mt-auth-id-content {generic}} 

RLC AUTHENTICATION 



({moreO, 

mt-auth-id-type generic, 
mt-auth-id-content {generic}} ) 



RLC AUTHENTICATION 



({more 0, 

mt-auth-id-type generic, 
mt-auth-id-content {generic}} 



— X T_key_exchange_ap 
— X T_link_capability_ack 

ACF_auth_mt_ind 

► 

(ACF-AUTHENTICATION-ARG ) 



ACF_auth_mt_rsp 

-* 

( ACF-AUTHENTICATION-MT-ARG) 

RLC_AUTHENTICATION_MT 

( {challenge-to-mt}) X T_authentication_mt 



Challenge_To_MT_Received 



Diagram 13: Authentication Generic 
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5.1.1.6 



Authentication based on different key types 



5.1.1.6.1 



Authentication with pre-shared key 



The MT shall send a challenge to the AP as well as the calculated response. How the response shall be calculated is 
described in clause 5.1.2.6.3. 



MSC Authentication_AP_Pre_Shared 


MT_ENV MT_RLC AP_RLC AP_ENV 




\ Challenge_To_MT_Receivecl y 




ACF_auth_ap_req 


) 
RLC_AUTHENTICATION_AP 


\/ T authentication mt 


IG ) 


(ACF-AUTHENTICATION-AP-ARG 


({challenge- to -ap, 
mt-response-1} ) 


Tauthenticationap 


ACF_auth_apJnd 


(ACF-AUTHENTICATION-AP-AF 


<' Challenge_To_AP_Received y 













Diagram 14: Authentication AP Pre-shared 
Table 17: RLC-AUTHENTICATION-AP-1 



RLC-AUTHENTICATION-AP-1-ARG ::= SEQUENCE { 



ric-pdu-type 

challenge-to-ap 

mt-response-1 



RLC-LCH-PDU-TYPE 
CHALLENGE 
AUTH-RESP0NSE-PART1 } 



Table 18: RLC-AUTHENTICATION-AP-2 



RLC-AUTHENTICATION-AP-2-ARG ::= SEQUENCE { 



rIc-pdu-type 
mt-response-2 



RLC-LCH-PDU-TYPE 
AUTH-RESP0NSE-PART2 } 



Table 19: RLC-AUTHENTICATION-AP-3 



RLC-AUTHENTICATION-AP-3-ARG ::= SEQUENCE { 



rIc-pdu-type 
mt-response-2 



RLC-LCH-PDU-TYPE 
AUTH-RESPQNSE-PART2 } 



The AP shall send the calculated response to the MT. How the response shall be calculated described in 
clause 5.1.2.6.4. 
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MSC Authentication Ack Pre Shared 



MT ENV 



MT RLC 



AP RLC 



AP ENV 



Challenge_To_AP_Received 



ACF_auth_ap_rsp 



T authentication ap 

X 

ACF_autti_ap_cnf 



( AC;F-AUTHENTICATION-ACK-ARG) 
RLC AUTHENTICATION ACK 1 



( ap-response-2) 



T authentication ack 



ACF-AUTHENTICATION-ACK-ARG) 



Authenticated 



Diagram 15: Authentication Acit Pre-shiared 



Table 20: RLC-AUTHENTICATION-ACK-1 



RLC-AUTHENTICATION-ACK-1-ARG ::= SEQUENCE { 



ric-pdu-type RLC-LCH-PDU-TYPE 

ap-response-2 AUTH-RESP0NSE-PART2 } 



Table 21 : RLC-AUTHENTICATION-ACK-2 



RLC-AUTHENTICATION-ACK-2-ARG ::= SEQUENCE { 



rIc-pdu-type RLC-LCH-PDU-TYPE 
ap-response-2 AUTH-RESPQNSE-PART2} 



Table 22: RLC-AUTHENTICATION-ACK-3 



RLC-AUTHENTICATION-ACK-3-ARG ::= SEQUENCE { 



rIc-pdu-type RLC-LCH-PDU-TYPE 

ap-response-2 AUTH-RESPQNSE-PART2} 
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5.1.1.6.2 



Authentication based on 512 bit RSA signature (OAP/OMT) 



The MT shall send a challenge to the AP as well as the calculated response. How the response shall be calculated is 
described in clause 5.1.2.6.4. 



MSC Authentication_AP_RSA_Signature_512 



MT_ENV 




MT_RLC 




AP_RLC 




AP_ENV 

























Ch al I eng e_To_M T_R ece i ved 



ACF_auth_ap_req 



(ACF-AUTHENTICATION-AP-ARG ) 



T_authentica1ion_ap ^ 



RLC AUTHENTICATION AP 1 



({challenge- to-ap, 
mt-response-1} ) 

RLC AUTHENTICATION AP 2 



{{mt-response-2} 



T_authentication_mt 

X 

ACF_aiJth_ap_ind 



(ACF-AUTHENTICATION-AP-AFiG 



Ch all eng e_To_A P_Rece ived 



Diagram 16: Authentication AP RSA Signature 512 

The RLC_AUTHENTICATION_AP_l and RLC_AUTHENTICATION_AP_2 messages are defined in 
clause 5.1.1.6.1. 

The AP shall send the calculated response to the MT. How the response shall be calculated is described in 
clause 5.1.2.6.4. 



MSC Authentication_Ack_RSA_Signature_51 2 



MT ENV 



MT RLC 



AP RLC 



AP ENV 



Challenge_To_AP_Receivecl 



T_authentication_ap 



ACF_aiJth_ap_cnf 



ACF-AUTHENTICATION-ACK-ARG) 



( ac;f-authentication-ack-arg) 



RLC AUTHENTICATION ACK 1 



{ {ap-response-2}) 
RLC AUTHENTICATION ACK 2 



( {ap-response-2}) 



ACF_auth_ap_rsp 



T authentication ack 



Authenticated 



Diagram 17: Authentication AcW RSA Signature 512 
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The RLC_AUTHENTICATION_ACK_l and RLC_AUTHENTICATION_ACK_2 messages are defined in 

clause 5.1.1.6.1. 



5.1.1.6.3 



Authentication based on 768 bit RSA signature (OAP/OMT) 



The MT shall send a challenge to the AP as well as the calculated response. How the response shall be calculated is 
described in clause 5.1.2.6.4. 



MSC Authentication_AP_RSA_Signature_768 



MT_ENV 




MT_RLC 




AP_RLC 




AP_ENV 

























Chall enge_To_MT_Received 



ACF_auth_ap_req 



(ACF-AUTHENTICATION-AP-ARG ) rlc AUTHENTICATION AP 1 



({challenge- to-ap, 
mt-response-1} ) 

RLC AUTHENTICATION AP 2 



T_aLithenti cation_ap 

X — 



({mt-response-2} ) 
RLC AUTHENTICATION AP 3 



({mt-response-2} ) 



T authentication mt 



ACF_auth_ap_ind 



(ACF-AUTHENTICATION-AP-AFiG ) 



Chall enge_To_AP_Receivecl 



Diagram 18: Authentication AP RSA Signature 768 

The RLC_AUTHENTICATION_AP_l, RLC_AUTHENTICATION_AP_2 and RLC_AUTHENTICAT10N_AP_3 
messages are defined in clause 5.1.1.6.1. 

The AP shall send the calculated response to the MT. How the response shall be calculated is described in 
clause 5.1.2.6.4. 
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MSC Authentication_Ack_RSA_Signature_768 



MT ENV 



MT RLC 



AP RLC 



AP ENV 



Ch al lenge_To_AP_R ece ived 



T authentication ap 

X 

ACF_auth_ap_cnf 



ACF-AUTHENTICATION-ACK-ARG) 



RLC AUTHENTICATION ACK 1 ( 



( {ap-response-2}) 
RLC AUTHENTICATION ACK 2 



( {ap-response-2}) 



ACF_auth_ap_rsp 



ACF-AUTHENTICATION-ACK-ARG) 



T authentication ack 



Authenticated 



Diagram 19: Authentication Acit RSA Signature 768 

The RLC_AUTHENTICATION_ACK_l and RLC_AUTHENTICATION_ACK_2 messages are defined in 

clause 5.1.1.6.1. 



5.1.1.6.4 



Authentication based on 1 024 bit RSA signature (OAP/OMT) 



The MT shall send a challenge to the AP as well as the calculated response. How the response shall be calculated is 
described in clause 5.1.2.6.4. 



MSC Authentication_AP_RSA_Signature_1 024 



Ch al len ge_To_MT_R ece ived 



ACF_auth_ap_req 



(ACF-AUTHENTICATION-AP-ARG ) RLC_AUTHENTICATI0N_AP_1 

({challenge- to-ap, 
mt-response-1} ) 

RLC AUTHENTICATION AP 2 



T_authentication_ap 



({mt-response-2} ) 
RLC AUTHENTICATION AP 3 



MT_ENV 




MT_RLC 




AP_RLC 




AP_ENV 

























({mt-response-2} 



T authentication mt 



ACF_auth_ap_ind 



(ACF-AUTHENTICATION-AP-ARG 



Ch al len ge_To_AP_R ece ived 



Diagram 20: Authientication AP RSA Signature 1 024 
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The RLC_AUTHENTICATION_AP_l, RLC_AUTHENTICATION_AP_2 and RLC_AUTHENTICATION_AP_3 

messages are defined in clause 5.1.1.6.1. 

The AP shall send the calculated response to the MT. How the response shall be calculated is described in 
clause 5.1.2.6.4. 



MSC Authentication_Ack_RSA_Signature_1024 

MT ENV MT RLC 



AP RLC 



AP ENV 



Ch al len ge_To_AP_R ece ived 



T_authentication_ap 



ACF_auth_ap_cnf 



ACF-AUTHENTICATION-ACK-ARG) 



RLC AUTHENTICATION ACK 1 ( 



( {ap-response-2}) 
RLC AUTHENTICATION ACK 2 



( {ap-response-2}) 
RLC AUTHENTICATION ACK 3 



( {ap-response-2}) 



ACF_auth_ap_rsp 



ACF-AUTHENTICATION-ACK-ARG) 



T authentication ack 



Authenticated 



Diagram 21 : Authentication Acit RSA Signature 1 024 

The RLC_AUTHENTICATION_ACK_l, RLC_AUTHENTICATION_ACK_2 and 
RLC_AUTHENTICATION_ACK_3 messages are defined in clause 5.1.1.6.1. 
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5.1.1.7 



DM Common Key Distribution (OAP/OMT) 



The AP shall inform the MT about the encryption algorithm, the KEY ID and common key that shall be used for direct 
mode encryption. The MT shall confirm that the encryption algorithm and that the direct mode encryption key have 
been received. 



MSC DM_Common_Key_Distribution 

MT ENV MT RLC 



AP RLC 



AP ENV 



MT Associated to AP 



ACF_dm_common_key_distr_ind 



ACF-DM-COMMON-KEY-DISTR-,\RG) 



ACF_dm_common_key_distr_rsp 



( ,\CF-DM-COMMON-KEY-DISTR-ARG) 



RLC DM COMMON KEY DISTR 



( {dm-encr-alg, 

key- id, 

common -key}) 



(ACF-DM-COMMON-KEY-DISTR-ACK-ARG 

RLC DM COMMON KEY DISTR A 



({dm-encr-alg, 
md5 -on-key} ) 



ACF_d m_co mmo n_key_distr_req 



T_d m_c ommo n_key_di str 



— X T_link_capability_ack 
— X T_key_exchange_ap 
— X T_authentication_ack 
— X T_dm_common_key_distr_ack 

ACF_dm_common_key_distr_cnf 



(ACF-DM -COMMON- KEY-DISTR-ACK-ARG 



MT Associated to AP 



Diagram 22: DM Common Key Distribution 



Table 23: RLC-DIV!-COI\fllVION-KEY-DISTR 



RLC-DM-COMMON-KEY-DISTR-ARG ::= SEQUENCE { 



ric-pdu-type 
dm-encr-alg 
key-id 
common-key 



RLC-LCH-PDU-TYPE 
ENCR-INFO 
KEY- ID 
COMMON-KEY} 



Table 24: RLC-DM-COMMON-KEY-DISTR-ACK 



RLC-DM-COMMON-KEY-DISTR-ACK-ARG ::= SEQUENCE ■ 



rIc-pdu-type 
dm-encr-alg 
md5-on-key 



RLC-LCH-PDU-TYPE 

ENCR-INFO 

MD5-0N-KEY} 
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5.1 .1 .8 Info Transfer procedure (OAP/OMT, depends on CL and DLC) 

The MTs and AP/CC may use this function to exchange convergence layer or DLC layer information. 

In centralized mode (RLC messages sent over the DCCH in the uplink down link phase), the Info Transfer procedure is 
always initiated by the MT. Therefore, the MT shall use the RLC_INFO message and the AP/CC shall use the 
RLC_INFO_ACK message. The AP shall send the RLC_INFO_ACK as a response to the RLCJNFO message. 

In direct mode (RLC messages sent over the DCCH in the direct link phase), the Info Transfer procedure may be 
initiated by either a MT or the AP/CC. The MT or AP/CC receiving a RLC_INFO message shall send the 
RLC_INFO_ACK message as a response. 

Info Transfer procedure shall run at the end of the association phase. It may also run at any time after one MT has been 
associated. 

In case of multiple CLs the MT or AP/CC shall check the CL-ID in the RLC_INFO_ACK to associate the respond with 
corresponding request. 

During the association phase, several RLC_INFO messages may be sent in sequence. The number of messages depend 
from the supported convergence layers. 

The INFO-TYPE field in the RLCJNFO message indicates whether the RLC_INFO is a new RLCJNFO message or 
the retransmission of a non-acknowledged, and already sent RLCJNFO message. 

The INFO-COUNT field is used in different ways in the association phase and outside the association phase. 

• In the association phase, the INFO-COUNT field is used to indicate to the peer entity the number of remaining 
RLCJNFO messages to be transmitted for the whole set of supported convergence layers during the association 
phase. 

• Outside of the association phase, the INFO-COUNT field is used so that the RLC JNFO_ACK can be associated 
to the corresponding request of a single Info Transfer procedure. When a MT or AP/CC sends a 

RLC JNFO_ACK message, it shall use the same INFO_COUNT as found in the RLCJNFO. When a MT or 
AP/CC sends a RLCJNFO message, it shall: 

use the same INFO_COUNT as the previous RLCJNFO if it is running an error recovery process (timeout 
expired to get the RLCJNFO_ACK); 

decrease the INFO_COUNT by one (compared to the previous RLCJNFO) if it is starting a new Info 
Transfer procedure. 
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MSC lnfo_Transfer 

MT ENV 



MT RLC 



AP RLC 



AP ENV 



Link_Agreed_or_Encryption_actN/e_or_Authenticated 



ACF_info_req 



(ACF-INFO-ARG 



RLC INFO 



T info 



({info-type, 
info- count, 
cl-data, 
dic-attributes} 



RLC INFO ACK 



ACF info cnf 



{ ACF-INFO-ACK-ARG) 



( {info-count, 

cl-data, 

dIc-attributes}) 



MT Associated to AP 



TJin k_capabi lity_ack 

T_key_exch an ge_ap 

T_authenlica1ion_ack 

T_d m_co mmo n_key_di str_ack 

T_nw_signalling_handover_ack 



ACF info ind 



(ACF-INFaARG ) 



ACF_info_rsp 



( ACF-INFO-ACK-ARG) 



T info ack 



Diagram 23: Info Transfer 



Table 25: RLC-INFO 



RLC-INFO-ARG : 


= SEQUENCE { 


ric-pdu-type 


RLC-LCH-PDU-TYPE 


info-type 


INFO-TYPE 


info-count 


INFO-COUNT 


cl-data 


CL-DATA OPTIONAL 


dIc-attributes 


DLC-ATTRIBUTES OPTIONAL } 



Table 26: RLC-INFO-ACK 



RLC-INFO-ACK-ARG ::= SEQUENCE { 



rIc-pdu-type RLC-LCH-PDU-TYPE 

info-count INFO-COUNT 

cl-data CL-DATA OPTIONAL 

dIc-attributes DLC-ATTRIBUTES OPTIONAL } 
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5.1 .2 Key Management 

5.1.2.1 General 

Key management consists of key generation and refresh as well as handling of keys to various BRAN external entities 
such as key databases. Only those parts of key management that are necessary for interoperability are included in the 
HIPERLAN/2 standard. 

The keys used for authentication are long-term keys. They shall be available at both MT and AP side before 
authentication (if desired) can take place. How to generate, configure, store or fetch the keys (and public key 
certificates) are outside the scope of HIPERLAN/2 standards. 

Keys are needed for unicast and broadcast/multicast encryption. Both types of keys are short-term and can be refreshed. 
The interval for key refresh is regulated by the local security policy. 

The unicast key SSK (Session Secret Key) is a secret key known only to one MT and its connected AP. As the name 
("session") implies it is valid for a limited period. 

Unicast key generation during initial association is described in clause 5.1.2.5. 

5.1 .2.2 Unicast Key Refresh (GAP) 

SSK should be refreshed regularly to maintain security. When the key lifetime expires, a new SSK key should replace 
the old one. It is preferable to start the key refresh process before the current key expires. 

When the current SSK is going to expire, the AP should send a random value nonce encrypted with the current SSK, 
that is, SSK(nonce), to the MT. Upon receiving, the MT shall decrypt nonce, calculate the new encryption key SSK' and 
send a hash value of the nonce MD5(nonce) back to the AP as confirmation. The AP shall verify the hash value to make 
certain that nonce has been correctly received by the MT. After that the AP should send more than one 
RLC_UNICAST_KEY_ACTIVATE signal to the MT. In this signal the last-mac-frame parameter indicates the last 
MAC frame until which the current SSK is valid. Starting from the next frame, that is the (last-mac-frame 1)* frame, 
both parties shall use SSK'. Both the MT and AP shall compute the SSK' as follows: 

KeyMat = Kl | K2 | K3 I ... 

Where 

Kl = HMAC-MD5 (g"^ mod n, nonce) 

K2 = HMAC-MD5 (g"* mod n, Kl | nonce) 
K3 = HMAC-MD5 (g"^ mod n, K2 i nonce) 
etc . 
Kl contains the most significant bits of the concatenated KeyMat. 

g''y mod n is the Diffie-Hellman secret obtained during the last execution of the encryption startup procedure. 
The SSK' shall be derived from the KeyMat as described in clause 5.1.2.5. 
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MSC Unicast_Key_Refresh 

MT ENV I MT RLC 



AP RLC 



AP ENV 



MT Associated to AP 



|CF-UNICAST-KEY-REFRESH-ARG) 
ACF_unicast_key_refresh_rsp 



ACF_unicast_key_refresh_incl 



(ACF-UNICAST-KEY-REFRESH-ACtf-ARG ) 

RLC UNICAST KEY REFRESH 



ACF_unicast_key_activate_incl 



( ACF-UNICAST-KEY-ACTIVATE-ARG) 



( ACIf-UNICAST-KEY-REFRESH-ARG) 
RLC UNICAST KEY REFRESH 



( {nonce}) 



ACK 



({mdS-on-nonce} 



(ACF 



( ACF 
RLC UNICAST KEY ACTIVATE 



( last-mac-frame) 



ACF_unicast_key_refresh_req 



T_u nicast_key_ref resh 



ACF_unicast_key_refresh_cnf 



UNICAST-KEY-REFRESH-ACK-APG 
ACF_un icast_key_activate_req 



UN ICAST-KEY-ACTI VATE-ARG) 



MT Associated to AP 



Diagram 24: Unicast Key Refresh 
Table 27: RLC-UNICAST-KEY-REFRESH 



RLC-UNICAST-KEY-REFRESH-ARG ::= SEQUENCE { 



ric-pdu-type RLC-LCH-PDU-TYPE 
nonce NONCE } 



Table 28: RLC-UNICAST-KEY-REFRESH-ACK 



RLC-UNICAST-KEY-REFRESH-ACK-ARG ::= SEQUENCE { 



ric-pdu-type RLC-LCH-PDU-TYPE 

md5-on-nonce MD5-QN-NQNCE } 



Table 29: RLC-UNICAST-KEY-ACTIVATE 



RLC-UNICAST-KEY-ACTIVATE-ARG ::= SEQUENCE { 



ric-pdu-type RLC-SCH-PDU-TYPE 

iast-mac-frame LAST-iVlAC-FRAiVIE} 
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5.1 .2.3 Common keys (OAP/OMT) 

5.1.2.3.1 General 

Common keys are used for encryption of multicast and broadcast user data and are used if encryption is chosen in the 
join procedure. Common keys are also used for the encryption of DiL data. Every common key shall be associated with 
an identifier (key-id). 

The AP shall generate and distribute common keys to MTs. One common key may be used for broadcast only, for one 
multicast group only, for more than one multicast group, or for both broadcast and multicast. If the encryption is chosen 
to be used, the AP shall encrypt multicast/user broadcast data with a common key using a chosen algorithm. It is 
assumed that all MTs in the cell support this encryption algorithm. The decision for the algorithm shall be made by the 
AP. 

Common keys shall be generated by APs on a stand-alone basis. A random number generator should be used to produce 
the KeyMat. 

NOTE: The random number generator should produce random numbers with good characteristics to get a secure 
system. Implementers should strive for good random properties for the random generator output 
(see bibliography, "Applied cryptography Second Edition" and "Randomness Recommendations for 
Security" for further information about this subject). 

A common key shall be derived from the KeyMat as described in clause 5.1.2.5. 

5.1 .2.3.2 DM Common Key Distribution (OAP/OMT) 

The DM Common Key Distribution is introduced in clause 5.1.1.7. 

5.1 .2.3.3 Common Key Refresh (OAR) 

When it is time to refresh a common key, the AP should generate a new common key as described in clause 5.1.2.3.1. 
The AP shall send the new key to every related MT encrypted with the respective unicast key. The key identifier shall 
tell MTs which common key is to be updated. Each MT shall decrypt and send back a hash value as confirmation. 

After receiving confirmation from all the related MTs in the cell, the AP should send out more than one 
RLC_COMMON_KEY_ACTIVATE broadcast message to activate the common key. The last-mac-frame parameter 
indicates the last MAC frame until which the old common key is valid. Starting from the next frame, that is the (last- 
mac-frame + 1)* frame, the new common key shall be used. If the key identifier contained in the activation message is 
unknown to the MT, the MT shall ignore the message. 
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MSC Common_Key_Refresh 



MT ENV 



MT RLC 



AP RLC 



AP ENV 



ACF_common_key_refresh_ind 



(ACF-COMMON-KEY-REFRESH-ARG) 



AC F_com mon_key_ref res h_rsp 



(^CF-COMMON-KEY-REFRESH-ACK-ARCi) 



ACF_common_key_activate_ind 



( ACF-C(DMMON-KEY-ACTIVATE-ARG) 



MT Associated to AP 



RLC COMMON KEY REFRESH 



( {encr-info, 

key-id, 

common-key} 



RLC COMMON KEY REFRESH 



AC< 



; {encr-info, 
md5-on-key}) 



RLC COMMON KEY ACTIVATE 



( {key-id, last-mac -frame}) 



ACF_common_key_refresh_req 



( ACF-COMMON-KEY-REFRESH-ARG) 



T_common_key_refresh 

Common_Key is the new K 
key for the already used 
Key_ID, i.e., it will replace 
the old key which is currently 
associated to that Key_ID 



ACF_common_key_refresh_cnf 



[ ACF-COMMON-KEY-REFRESH-ACK-ApG ) 
ACF_common_key_activate_req 



( ACF-COMMON-KEY-ACTIVATE-ARG 



This message should be sent in [\ 
RBCH more than once to tell the 
MTs that the old key is valid until 
the last-mac-frame. Starting from 
the next frame the new key shall 
be used 



MT Associated to AP 



Diagram 25: Common Key Refresh 



Table 30: RLC-COMMON-KEY-REFRESH 



RLC-COMMON-KEY-REFRESH-ARG : 


= SEQUENCE { 1 


ric-pdu-type 


RLC-LCH-PDU-TYPE | 


encr-info 


ENCR-INFO 




key-id 


KEY-ID 




common-key 


COMMON-KEY} 





Table 31 : RLC-COMMON-KEY-REFRESH-ACK 



RLC-COMMON-KEY-REFRESH-ACK-ARG ::= SEQUENCE { 



rIc-pdu-type 

encr-info 

md5-on-key 



RLC-LCH-PDU-TYPE 

ENCR-INFO 

MD5-0N-KEY} 



Table 32: RLC-COMMON-KEY-ACTIVATE 



RLC-COMMON-KEY-ACTIVATE-ARG ::= SEQUENCE { 



rIc-pdu-type RLC-SCH-PDU-TYPE 

key-id KEY-ID 

last-mac-frame LAST-MAC-FRAME } 
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5.1 .2.4 RBCH-Seed Transfer 



Seed shall be used to support IV generation that is needed for encryption. A seed shall be transferred to the MT in the 
RBCH. The following rules apply to handling of the seed transfer: 

1) The seed shall be sent repeatedly in each Nth frame when the AP supports encryption. The AP may send the seed 
also whenever needed. 

2) The seed transmission shall be synchronized with the used sleep cycles. 

3) A MT that intends to use encryption shall from the start of the RLC_LINK_CAPABITY message (in both 
Association and NW Handover) try to update its internal seed generator. The AP shall provide at least one seed 
value during the Link Capability/HO Link Capability and Encryption Start-up/Token-Signalling procedures 
during Association and Network Handover. The value for the repetition of seed (N) is vendor specific. 

4) The MT shall receive a seed before starting the procedure that follows encryption start up/Token Signalling. 

NOTE: Data will be lost during N frames if a residual error occurs at reception of the seed in the MT. Care should 
therefore be taken to avoid too high N values. 

5.1 .2.5 Encryption key calculations 

5.1.2.5.1 Diffie-Hellman Key Exchange 

A Diffie-Hellman Key Exchange [21] shall be carried out in the association phase to generate the unicast encryption 
key. The two parameters required by the Diffie-Hellman (DH) key exchange, a base generator g and a big prime 
number n, shall be pre-configured to the following value in both MT and AP: 

g = 2 

n = 2'^^^ - 2'^°'' - 1 + 2^'' X {[2] + 149 686} (Oakley group 1, see [21]) 

The hexadecimal value of n is: 

FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 8A67CC74 
020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 302B0A6D F25F1437 
4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF 

During the Diffie-Hellman Key Exchange, both MT and AP shall generate a random number as their DH private value, 
say MT has x and AP has y. The MT shall calculate its DH public value MtDhPublicValue = g" mod n and send it to the 
AP. Likewise the AP shall calculate ApDhPublicValue = gy mod n and send it to the MT. After that both the MT and 
AP shall calculate the keying material as described in the following clauses. 

NOTE: The Diffie-Hellman key exchange relies on random numbers with good characteristics to get a secure 

system. Implementers should strive for good random properties for the random number generator output 
(see bibliography, "Applied cryptography Second Edition" and "Randomness Recommendations for 
Security" for further information about this subject). 

The MT shall calculate the relevant encryption key before sending the first message after the Encryption Startup 
procedure. 
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5.1 .2.5.2 DES Key Calculation 



For DES [ 1 ] encryption, 

KeyMat = HMAC-MD5(g''y mod n, x 00), (HMAC-MD5 is explained in clause 5.1.2.6.1). 

in which the first (most significant) 8 octets shall be taken out as the session key SSK. The least significant bit in each 
octet of SSK shall be the parity bit, and it shall be set according to [2] . 

The SSK shall be checked against all weak and semi-weak keys (keys that have a dual) [2] known to the DES algorithm. 
If SSK is weak or semi-weak, a new KeyMat shall be generated by increasing the second parameter in the HMAC-MD5 
function, that is, compute: 

KeyMat = HMAC-MD5 (g^^ mod n. Ox 01) 
KeyMat = HMAC-MD5 (g^^ mod n. Ox 02) 

until a non-weak and non-semi-weak key is obtained. 

5.1 .2.5.3 Calculation of Triple DES keys (OAP/OMT) 

The key used for the first DES encryption module (that receives the IV) is called keyl, the key for the second DES 
decryption module is called key2 and the key for the last DES encryption module is called key3. 

KeyMat = Kl 1 K2 

Where: 

Kl = HMAC-MD5 (g^y mod n. Ox 00) 

K2 = HMAC-MD5 (g^y mod n, Kl | Ox 00), 

Kl contains the most significant bits of the concatenated KeyMat. 

The first (most significant) 8 octets of KeyMat shall be taken as keyl, the next 8 octets shall be taken as key2 and the 
next 8 octets as key3. The least significant bit in each octet of the keys shall be the parity bit. The parity bits shall be 
calculated according to [2]. 

For the three keys (keyl, key! and key3), the following checks shall be performed: 

- check each of them against all weak and semi-weak keys known to the DES algorithm [2]; 

- check that all three keys are different. 

If any of the checks above fails a new KeyMat is generated by increasing the second parameter in the HMAC-MD5 
function, that is, compute: 

KeyMat = Kl 1 K2 

Where: 

Kl = HMAC-MD5 (g^y mod n. Ox 01) 

K2 = HMAC-MD5 (g^y mod n, Kl 1 Ox 01) 

KeyMat = Kl | K2 

Where: 

Kl = HMAC-MD5 (g^y mod n. Ox 02) 

K2 = HMAC-MD5 (g^y mod n, Kl ( Ox 02) 

until non-weak, non-semi-weak and different keys are obtained. 
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5.1 .2.5.4 Unicast Key Generation at Network Handover (Mandatory if Handover supported) 

The network handover procedure is described in clause 5.2.1.3. 

A new SSK for unicast encryption shall be generated at the end of each successful network handover. Both the MT and 
new AP shall calculate a new KeyMat as follows: 

KeyMat = Kl 1 K2 i K3 I ... 

Where: 

Kl = HMAC-MD5 (g^y mod n, nonce) 

K2 = HMAC-MD5 (g^y mod n, Kl 1 nonce) 
K3 = HMAC-MD5 (g^y mod n, K2 | nonce) 

etc. 

Kl contains the most significant bits of the concatenated KeyMat. 

in which, 

g''y mod n is the earlier established Diffie-Hellman secret, nonce is a random value contained in the handover token. 

The new SSK shall be derived from the KeyMat as described in clause 5.1.2.5. 

Nonce + 1, nonce + 2, ..., shall be used as the second parameter in the HMAC-MD5 calculation if the first key check 
fails. The value is increased by one until the key check procedure gives a successful result. 

5.1.2.6 Authentication functions 

5.1.2.6.1 Algorithms 

MD5 and HMAC are mandatory to implement, since DES encryption is mandatory to implement, whereas RSA is 
optional to implement. All are optional to use. 

MD5 (Message Digest 5), [6] is a one-way hash algorithm developed by RSA Data Security, Inc. It can be used to hash 
an arbitrary-length byte string into a 128-bit value. 

HMAC (Message Authentication with keyed Hashing) [7] is a mechanism for message authentication using keyed hash 
algorithms. HMAC-MD5 works as follows: 

- HMAC-MD5(k, m) = MD5((k XOR opad) I MD5((k XOR ipad) I m)); 

in which k is the secret key, m is the message, ipad (inner padding) is x 36 repeated 64 times, opad (outer padding) is 
X 5c repeated 64 times, "XOR" is exclusive OR, and T is concatenation. 

RSA (see bibliography, "A Method for Obtaining Digital Signatures and Public-Key Cryptosystems, Communications 
of the ACM") is a public-key algorithm. It can be used for digital signatures. Assume a user A has a pair of RSA keys, a 
private key PrivKey^ and a public key PubKey^. A can digitally sign a message m by first hashing m and then 

encrypting the hash value with PrivKeyA- Anyone can verify A's signature by decrypting it with PubKey^ and then 

checking the hash value. 



£75/ 



49 ETSI TS 101 761-2 VI .3.1 (2002-01) 



5.1.2.6.2 Authentication protocols 



In the association phase, if authentication is chosen, it shall be performed after the Diffie-Hellman key exchange 
(see Encryption Startup MSC). 

NOTE 1 : To detect man-in-the-middle attacks that, over the radio link, are difficult but yet potentially possible to 
launch with DH exchange, the DH public values exchanged are linked to the authentication procedure. 
Proposed and selected encryption and authentication alternatives are also included to combat attacks 
aiming for a lower security level than requested. 

The authentication protocol shall be negotiated between the AP and the MT. Five alternatives are specified: 

1) Pre-shared key based; 

2) RSA512(OAP/OMT); 

3) RSA768 (OAP/OMT); 

4) RSA1024 (OAP/OMT); 

5) No authentication. 

If authentication is chosen, either pre-shared key based or public key (RS A) based, a challenge-response scheme shall 
fulfil the task. The challenge should be a random number sent by the verifier to the claimant. The claimant shall 
calculate a response using a function with the challenge as input. The function to use depends on which alternative ( 1 or 
2 to 4) is chosen. 

If the MT authentication succeeds, the MT is allowed to access the network and the association procedure should 
continue. Otherwise the MT shall be rejected and the DLC connection between the MT and AP shall be terminated. The 
MT may also terminate the access attempt if the AP authentication fails. 

NOTE 2: The challenge-response scheme needs a random number with good characteristics to get a secure system. 
Implementers should strive for good random properties for the random number generator output 
(see bibliography for further discussion on this subject). 

5.1 .2.6.3 Pre-shared key based authentication 

In this alternative a party is authenticated if it has knowledge of the pre-shared key. In this case, the key shall be 
generated and distributed to the communicating parties in advance. 

NOTE: Because of key management overhead, this solution is primarily applicable to business and residential 
environment with a limited number of users and administrative domains. 

The response shall be calculated as follows when pre-shared keys are used: 

- mt-response = HMAC-MD5(PresharedKey, Mt Authentications tring); 

if encryption is chosen, i.e. Encryption Startup has preceded the authentication procedure; 

MtAuthenticationString = challenge_to_mt I mt_dh_public_value I ap_dh_public_value I authentication_encryption_list 
I auth_encr_selected. 

Otherwise: 

MtAuthenticationString = challenge_to_mt I authentication_encryption_list I auth_encr_selected; 

ap-response = HMAC-MD5(PresharedKey, APAuthenticationString). 

If encryption is chosen, i.e. Encryption Startup has preceded the authentication procedure, 

APAuthenticationString = challenge_to_ap I mt_dh_public_value I ap_dh_public_value I authentication_encryption_list 
I auth_encr_selected 

Otherwise: 

APAuthenticationString = challenge_to_ap I authentication_encryption_list I auth_encr_selected. 
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MtAuthenticationString and APAuthenticationString are concatenations of a few items. These items shall be 
concatenated in the same order (from left to right) as shown above. Each item shall be appended with the most 
significant bit first: 

challenge-to-mt: the challenge sent by AP to MT, 128 bit long; 

challenge-to-ap: the challenge sent by MT to AP, 128 bit long; 

mt-dh-public-value: MTs Diffie-Hellman public value, 768 bit long; 

ap-dh-public-value: AP's Diffie-Hellman public value, 768 bit long; 

authentication-encryption-list: the list of authentication-encryption alternatives proposed by MT during the link 
capability phase, n x 8 bit long (n is the number of authentication-encryption alternatives in the list); 

auth-encr-selected: the authentication-encryption alternative selected by AP during the link capability phase, 
8 bit long. 

The length of the pre-shared key should be at least 128 bits, see RFC 2104 [7]. 
5.1 .2.6.4 Public key based authentication (OAP/OMT) 

To use public -key cryptography, the most important thing is to assure the authentic binding between a public key and its 
owner. A public-key certificate signed by some trusted authority is an effective means to distribute public keys securely. 
A public key infrastructure (PKI) provides mechanisms to issue, fetch, verify or revoke public -key certificates. 

In this alternative a party is authenticated if it has the ability to correctly generate a digital signature. The signature and 
verification calculations shall be done as defined in [PKCS#1] using MD5 as hash algorithm. The response shall be 
calculated as follows when a public key solution is used: 

- mt-response = RSASSA-PKCS-Vl_5-SIGN(MtPrivKey,MtAuthenticationString); 

- ap-response = RSASSA-PKCS-Vl_5-SIGN(ApPrivateKey,ApAuthenticationString). 
MtAuthenticationString and ApAuthenticationString are the same as described in clause 5.1.2.6.3. 
Three public key lengths are supported: 512, 768 and 1 024 bits. 

5.1.3 Disassociation 

Disassociation is for releasing MT's association to a particular AP. There are two types of disassociation, 1) explicit and 
2) implicit. 

1) In the explicit disassociation either the MT or the AP initiates the disassociation. The initiating peer (either MT 
or AP) shall send the RLC_DISASSOCIATION message and the other peer shall respond with 
RLC_DISASSOCIATION_ACK message. After sending the RLC_DISASSOCIATION message or when 
receiving the same from MT, the AP should release the resources for the MT. 

2) The Implicit disassociation should take place when the MT and the AP have lost the ability to communicate via 
the radio interface. In this case, the MT_Alive process shall notice that the MT or/and AP can not be reached and 
the resources for the MT should be released by the AP. 

NOTE: In the MT Initiated Disassociation, the MT may not wait for the RLC_DISASSOCIATION_ACK. 
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MSC Mr_init_disassociation 



MAC_ID_ASSIGNED 



ACF_disassociation_req 



(ACF-DISASSOCIATION-ARG ) 



T_disassoc iat iai_mt 



ACF_disas93 ciatio n_cnf 



ACF-DISASSOCIATION-ACK-ARG) 



Terminate al 1 
DUCs 



RIjC_DISASSOCIATION 



((disassociation-caiise, 
mac-id } ) 



ACF_disassociation_ind 



(ACF-DB ASSOCIATION-ARG ) 

ACF_disasso ciat b n_rsp 



RLC_DISASSOCIATION_ACK 



TliisMT initiated 



( {mac -id}) 



ACF-DISASSOCIATION-ACK-ARG) disas sociatbn proceduK 
is optional 



Terminate all 
DUCs 



MT_ DISAS S0C1^TED_FR0]VL AP 



Diagram 26: MT Initiated Disassociation 



Table 33: RLC-DISASSOCIATION 



RLC-DISASSOCIATION-ARG ::= SEQUENCE { 



ric-pdu-type 

disassociation-cause 

mac-id 



RLC-SCH-PDU-TYPE 
DISASSOCIATION-CAUSE 
MAC-ID } 



Table 34: RLC-DISASSOCIATION-ACK 



RLC-DISASSOCIATION-ACK-ARG ::= SEQUENCE ■ 



ric-pdu-type 
mac-id 



RLC-SCH-PDU-TYPE 
iVIAC-ID - (if Upiini<) -} 
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MSC AP init disassociation 



MT ENV 



MT RLC 



ACF disassociatbn ind 



( ACF-DISASSOCIATION-ARG) 
ACF_disassociation_rsp 



(ACF-DISASSOCIATION-ACK-ARCi ) 



Terminate all 
DUCs 



AP RLC 



AP ENV 



MAC ID ASSIGNED 



RLC DISASSOCIATION 



( {disassociation-cause, 
mac- id}) 



RLC DISASSOCIATION ACK 



{{mac -id} 



ACF_disassociatbn_req 



( ACF-DISASSOCIATION-ARG) 



Tjdisassoci ation_ap 



ACF disassociation cnf 



(ACF-DISASSOCIATION-ACK-ARG ) 

Terminate all 
DUCs 



MT DISASSOCIATED FROM AP 



Diagram 27: AP Initiated Disassociation 

5.1.4 Multicast (OAP/OMT) 

In order to join multicast groups the MT shall first have to be associated to the AP as an individual and the MT should 
also have made connection set-ups for unicast traffic. If individual connections are not set up before the group join 
attempt, the AP cannot use the n x unicast method. 

There shall be two ways of implementing multicast: using multicast MAC ID and transmitting the information once to a 
multicast group over the air and n times unicast where the information is transmitted individually to each member of the 
group. 

The multicast MAC ID method shall use multicast MAC IDs from the range 224 to 255. 

The MT shall initialize the group joining by sending the RLC_GROUP_JOIN message to the AP. The MT shall use a 
higher layer address as the group identifier in the request. The MT shall also propose the encryption algorithms it wants 
to use. 

The AP shall acknowledge the request by sending MAC IDs and the selected encryption algorithm and keys for each 
group. Each RLC_GROUP_JOIN_ACK message shall have exactly one encryption algorithm, one common key and 
one key id and all HL addresses and all MAC-Ids having those security parameters. Other groups with other security 
parameters shall use other RLC_GROUP_JOIN_ACK messages. 

The MAC ID shall be either a Multicast MAC ID from the permitted range or the individual MAC ID that the MT is 
already using. If it is the MAC ID that the MT is already using, then the multicast traffic shall use one of the DLCC-IDs 
that the MT is already using. If it is a multicast MAC ID, then the DLCC-ID 63 shall be used. 

How the AP decides on the method, multicast or n x unicast, is not a part of the present document. 
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MS C Multic astGroupJoin 

MT ENV 



MT RLC 



AP RLC 



AP ENV 



MT_associated_or_GroupJoined 



ACF_groupJoin_req 



(ACF-GROUP-JOIN-ARG) 
T_groupjoin 



Rir._ GRniip_.iniN 

{cl-data, 
encryption-algorithm-proposal} 



ACF_group_ioin_ind 



(AGF-GRGUP-JGIN-ARG) 



loop <1 , 6> multicastJoin_ack 



Groupjoined 



Diagram 28: Multicast Group Join 
Table 35: RLC-GROUP-JOIN 



RLC-GROUP-JOIN-ARG ::= SEQUENCE { 



ric-pdu-type RLC-LCH-PDU-TYPE 

cl-data CL-DATA 

encryption-algorithm-proposal ENCRYPTION-ALGORITHM-PROPOSAL } 



MSC multicastJoin_ack 



MT ENV 



MT RLC 



( ACF-GROUP-JOIN-ACK-ARG ) 



ACF_gro up J oin_c nf 



AP_RLC AP_ 

ACF_grou pj oin_rsp 



ENV 



( ACF-GROUP-JOIN-ACK-ARG ) 
RLC GROUP JOIN ACK 



( {more-joins, 

mac-id-and-cl- data-list, 

group-encr-alg -selected, 

key-id, 

common -key}) 



Diagram 29: IVIulticast Group Join Ack 
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Table 36: RLC-GROUP-JOIN-ACK 



RLC-GROUP-JOIN-ACK-ARG::= 


SEQUENCE! 


ric-pdu-type 


RLC-LCH-PDU-TYPE 


more-joins 


MORE-JOINS 


mac-id-and-cl-data-list 


MAC-ID-AND-CL-DATA-LIST 


encryption-algorithm-selected 


ENCR-INFO 


key-id 


KEY- ID 


common-key 


COMMON-KEY} 



Table 37: RLC-GROUP-JOIN-NACK 



RLC-GROUP-JOIN-NACK-ARG::= SEQUENCE { 



ric-pdu-type 

cl-data CL-DATA } 



RLC-LCH-PDU-TYPE 



When a MX leaves a group, it shall send a group-leave-request to the AP. The MT shall use the higher layer address as 
the group identifier. The AP shall acknowledge the request positively and again use the higher layer address as an 
identifier. 



MSC MulticastGroupLeave 

MT ENV I I MT RLC 



AP RLC 



AP ENV 



Groupjoined 



ACF_group_leave_req 



(ACF-GROUP-LEAVE-ARG 



% 



T_group_leave 



RL C_G ROUP LEAVE 



({cl-data}) 



({cl-data}) 



ACF_grcup_leave_cnf 



( /!,CF-GROUP-LEAVE-ACK-ARG) 



ACF_grcup_leave_lnd 



(ACF-GROUP-LEAVE-ARG ) 
ACF_groupJeave_rsp 



RLC GROUP LEAVE ACHj / ,CF-GROUP-LEAVE-ACK-ARG) 



Dlsengaged_from_these_groups_StilLcommunicatlng_unlcast_and_other_groups_lf_any 



Diagram 30: Multicast Group Leave 



Table 38: RLC-GROUP-LEAVE 



RLC-GROUP-LEAVE-ARG::= SEQUENCE ■ 



ric-pdu-type 
cl-data 



RLC-LCH-PDU-TYPE 
CL-DATA } 



Table 39: RLC-GROUP-LEAVE-ACK 



RLC-GROUP-LEAVE-ACK-ARG::= SEQUENCE { 



ric-pdu-type 
ci-data 



RLC-LCH-PDU-TYPE 
CL-DATA } 
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5.1 .5 CL Broadcast (OAP/OMT, depends on CL) 

In order to join CL (user) broadcast groups the MT shall be first associated to the AP as an individual. 

The MT shall initialize the CL broadcast group joining by sending the RLC_CL_BROADCAST_JOIN message to the 
AP. The MT shall use a higher layer address as the broadcast group identifier in the request. The MT shall also propose 
the encryption algorithms it wants to use. 

The AP shall acknowledge the request by sending MAC IDs, HL-addresses, the selected encryption algorithm and keys 
for each group. 

The broadcast MAC ID can be any free MAC ID except the one used for RBCH signalling (MAC ID = 0) and the 
multicast MAC IDs from the range 224 to 255. The DLCC-ID value 63 shall be used for all broadcast traffic. The 
MAC-ID selected by the AP for broadcast transmission shall not be the one that is already being used for unicast 
transmission. 

The UBCH [5] shall be used for CL broadcast. 



MSC CLBroadcastJoin 

MT ENV 



MT RLC 



AP RLC 



AP ENV 



ASSOCIATED 



ACF_cl_broadcastJoin_req 



(ACF-CL-BROADCAST-JOIN-ARG [4 

X 
T_cl_broadcastJoin 



RLC CL BROADCAST JOIN 



({ cl-dala, 

broadcast-encrypt- alg-proposal } 



RLC CL BROADCAST JOIN ACK 



ACF_d_broadcastJoin_cnf 



( AC--CL-BROADCAST-JOIN-ACK-ARG) 



{ mo re -joins, 

error-corr-mode, 

window- size, 

mac-id-and-cl-data-list, 

encryption-selected, 

key-id, 

common-key}) 



ACF_d_broadcastJoin_ind 



(ACF-CL-BROADCAST-JOIN-ARG ) 
ACF_d_broadcastJoin_rsp 



ACF-CL-BROADCAST-JOIN-ACK-ARGi 



ASSOCIATED CL BROADCAST JOINED 



Diagram 31 : CL Broadcast Group Join 
Table 40: RLC-CL-BROADCAST-JOIN 



RLC-CL-BROADCAST-JOIN-ARG ::= SEQUENCE { 



ric-pdu-type RLC-LCH-PDU-TYPE 

cl-data CL-DATA 

encryption-algorithm-proposal ENCRYPTION-ALGORITHM-PROPOSAL } 
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Table 41 : RLC-CL-BROADCAST-JOIN-ACK 



RLC-CL-BROADCAST-JOIN-ACK-ARG::= SEQUENCE { 


ric-pdu-type 


RLC-LCH-PDU-TYPE 


more-joins 


MORE-JOINS 


error-corr-mode 


ERROR-CORR-MODE 


window-size 


BROAD-WINDOW 


mac-id-and-cl-data-list 


MAC-ID-AND-CL-DATA-LIST 


encryption-algorithm-selected 


ENCR-INFO 


key-id 


KEY- ID 


common-key 


COMMON-KEY} 



When a MT leaves a group, it shall send a group-leave-request to the AP. The MT shall use the higher layer address as 
the group identifier. The AP shall acknowledge the request positively and again use the higher layer address as an 
identifier. 



MSC CLBroadcastLeave 

MT ENV 



MT RLC 



AP RLC 



AP ENV 



ASSOCIATED CL BROADCAST JOINED 



(ACF-CL-BROADCAST-LEAVE-ARG 



ACF_d_broadcast_leave_req 



T cl broadcast leave 



ACF d broadcast leave cnf 



ACF-CL-BROADCAST-LEAVE-ACK-/\RG) 



RLC CL BROADCAST LEAVE 



(cl-data ; 



RLC 



{ ACF-CL 
CL BROADCAST LEAVE ACK 



( cl-data) 



ACF d broadcast leave ind 



(ACF-CL-BR0ADCAST-LEAVE-4RG 
ACF_d_broadcast_leave_rsp 



BROADCAST-LEAVE -ACK-ARG) 



ASSOCIATED 



Diagram 32: CL Broadcast Leave 
Table 42: RLC-CL-BRO ADC AST-LEAVE 



RLC-CL-BROADCAST-LEAVE-ARG ::= SEQUENCE 



ric-pdu-type 
cl-data 



RLC-LCH-PDU-TYPE 
CL-DATA } 



Table 43: RLC-CL-BRO ADC AST-LEAVE- ACK 



RLC-CL-BROADCAST-LEAVE-ACK-ARG ::= SEQUENCE 



ric-pdu-type 
cl-data 



RLC-LCH-PDU-TYPE 
CL-DATA } 
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5.1.6 Association Rejection 

The rejection of the Association procedure shall follow the next three rules: 

1) The information in RBCH Association does not fit with what is expected by the MT. The MT shall not continue 
the Association procedure. 

2) If the AP does not accept the RLC_MAC_ID_ASSIGN message, the AP shall respond with the 
RLC_MAC_ID_ASSIGN_NACK message. 

3) After the MT has got a MAC ID, the rejecting shall be done by sending RLC_DISASSOCIATION message. 
Both the MT and AP shall use this message for this purpose. The RLC_DISASSOCIATION message shall be 
used for every type of explicit disassociation during all states of the system, not only during the association 
phase. 

NOTE: Because of varying radio link conditions, the Disassociation may happen implicitly, see clause 5.1.3. 

5.2 Services supporting RRC (Radio Resource Control) 
5.2.1 Handover (OAP/OIVIT) 

Depending on the MT handover decision three types of handover can be performed: 

Sector Handover (Inter-Sector); 

Radio Handover (Inter-APT/Intra-AP Handover); 

Network Handover (Inter- AP/Intra-Network Handover). 

A radio cell shall be controlled by one APC, whereby APCs may support several transceivers (APT) and, hence, serve 
several radio cells [5]. 

NOTE 1 : The distinction between APC and APT is only relevant for radio handover, where the controlling RLC 

instance may remain the same, while the MAC instance changes. Therefore, for ease of description, in all 
clauses of this clause, except clause 5.2.1.2, this distinction is not referred explicitly. 

NOTE 2: When initiating a handover to an adjacent radio cell, the MT may not know if it initiates a radio or 
network handover. Therefore, a handover supporting MT should support radio as well as network 
handover procedures. 

NOTE 3: Prior to handover execution the MTs should gather relevant measurements on the frequency used by the 
current AP as well as on the frequencies used by candidate APs for a handover. In order to measure 
neighbouring APs, the MT may use MT Absence. 

NOTE 4: The reason to perform any kind of handover is out the scope of the present document. 
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5.2.1.1 



Sector Handover (OAP/OMT) 



Sector antennas are optional for APs. If the AP uses sectors, the AP shall support Sector Handover as shown in 
diagram 1. 

During the Sector Handover only the antenna sector of the AP shall be changed. 
MSC Sector Handover 



MT ENV 



MT RLC 



AP RLC 



AP ENV 



MT_asscicialBd_and_communicatincLvia_sector_old 



R R C_se ctor_h an do ver_r eq 



(RRC-SECTOR-HANDOVER-REQU^ST-ARG ) 

RLC SECTOR HANDOVER 



^ 



T_secto r_h a nd ove r_req 



RRC sector handover cnf 



REOL^ 



EST 



({sector-id -new, 
mac-d} 



If SCH available in Sector_old: 
otherwise in RCH of Sector nevl/ 



RRC sector handover ind 



(RRC-SE(pTOR-HANDOVER-REQUEST-ARG 
RRC_sector_handover_rsp 



( RF)C-SECTOR-HANDOVER-ACK-ARG) 
RLC SECTOR HANDOVER ACK 



send in new sector 



RR C-S ECTO R- HAN DOVE R-ACK-A F^G) 

MT_associatBd_and_communicatingLvia_sector_new 



Diagram 33: Sector handover 



Table 44: RLC-SECTOR-HANDOVER-REQUEST 



RLC-SECTOR-HANDOVER-REQUEST-ARG ::= SEQUENCE { 



ric-pdu-type 

sector-id-new 

mac-id 



RLC-SCH-PDU-TYPE 

SECTOR-ID 

MAC-ID } 



Table 45: RLC-SECTOR-HANDOVER-ACK 



RLC-SECTOR-HANDOVER-ACK-ARG ::= SEQUENCE { 



rIc-pdu-type RLC-SCH-PDU-TYPE } 



To perform a sector handover, the MT may send a sector handover request via the old sector, if a SCH is still available 
and feasible for this purpose (i.e. SCH is not needed for other purposes and communication in the old sector is still 
possible). If no SCH is available the MT shall send the request in the RCH of the new sector. After sending 
RLC_SECTOR_HANDOVER_REQUEST the MT shall change to the new sector before the next frame starts. The AP 
shall respond with the RLC_SECTOR_HANDOVER_ACK message via the new sector (in DCCH). 

NOTE: No Reset of ARQ parameters shall be made at sector handover. 
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5.2.1.2 



Radio (intra-AP) Handover (OAP/OMT) 



Radio Handover is an optional tool for AP implementations with more than one transceiver per AP (see figure 3). 

The following prerequisite is made in order to get the radio handover in the simple way it is described here. The central 
controller shall have control of both encryption key and seed for all APTs that are controlled by the central controller. 
The key and the seed shall be identical for all APTs controlled by the controller. 

In a multiple transceiver configuration, for each transceiver, a unique AP ID shall be assigned, i.e. multiple AP IDs are 
assigned to one AP. The AP may provide an address mask during association and handover which indicates the address 
range of the AP ID dedicated for transceiver identification. The parameter apt-address-length conveyed in 
RLC_LINK_CAPABILITY_ACK and RLC_HANDOVER_LINK_CAPABILITY_ACK messages shall indicate the 
number of bits assigned for transceiver identification starting from the least significant bit of the AP ID. 

NOTE 1 : Using this parameter for multiple transceiver APs allows the MT to distinguish between candidate radio 
cells for radio and network handover, respectively, before initiating the handover procedure. 

In case of single transceiver APs the apt-address-length shall be set to zero. 

Values of apt-address-length greater than zero shall be indicated only, when the AP supports radio handover (copy to 
parameter). In a single coverage area using APs with identical net-id the apt-address-length shall be set to the same 
value in all APs. 



NOTE 2: According to the above dependencies, the MT may not know if it initiates a radio or network handover, 
when the corresponding apt-address-length is set to zero, since both handover types are initiated by the 
MT with the same RLC message. 



Radio Handover 



Network Handover 




CL+HL 



EC 



L MAC 



PHY 



CL + HL 



EC 



MAC 



PHY 



MAC 



PHY 
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Figure 3: Informative radio and networit handover scenarios 

NOTE 3: Figure 3 is an example of APT-APC division and does not make any restrictions for implementation. 

NOTE 4: In such a configuration, a radio handover may be performed when an associated MT moves from the 
coverage area of one APT to another, which is served by the same APC. Since the handover execution 
may be performed within the DLC layer, the Higher Layer Protocols (HL) may not be involved. 
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MSC High_Level_Radio_Handover 



1(1) 



AssodatecLto APT_old 



Force Handover 



Radio Handover 



Associated to APT new 



Diagram 34: Radio hiandover overview 

If the MT is still synchronized to the current APT, when triggering a handover to another (target) APT, the MT may 
notify the AP via the current APT (RLC_HANDOVER_NOTlFY message), that it will perform a handover to another 
APT. 

NOTE 5: This message is only useful in case of network handover, since the AP is implicitly informed, when the 
MT initiates a radio handover. However, the MT may not be aware of the type of handover it initiates. 

The MT may return within 255 frames from the frame, where the RLC_HANDOVER_NOTIFY message was sent 
(sending frame is number 0). If the MT returns to the current APT it shall notify the AP. In case data waits for 
transmission in the MT, it sends Resource Requests to the AP and, hence, informs it thereby about its presence. In case 
no data has to be transmitted, the MT shall trigger the MT- ALIVE procedure. 
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MSC Radio Handover 

MT ENV 



MT RLC 



AP RLC 



AP ENV 



Associated to APT old 



°P' / RRC_handover_notify_req 

(RRC-HANDOVER-NOTIFY-ARb 



RLC HANDOVER NOTIFY 



({handover-cause, 
ap-id, 
net-id, 
mac- id} L 



RRC_handover_notifyJnd 



(RRC-HANDOVER-NOTIFY-ARG 



MT_synchronised_to_APT_new 



RRC_forward_liandover_req 



;rrc-handover-reouest-arg ) 

rlc handover reouest 



T_liandover_request 



RRC radio liandover cnf 



( F[RC-RADIO-HANDOVER-COIVIP 



{{ap-id -old, 
mac- id -old, 
net-id- old, 
due-established, 
mac- id 0} 



(F1RC-HAND0VER-RE0UEST-/!,RG ) 



( RRC-RADIO-H/^NDOVER-COMPLETE-ARG ) 
RLC RADIO HANDOVER COMPLETE 



.ETE-ARG ) 



{mac-id -old, 

ap-id -old, 

net- id- old, 

mac- id- new, 

cl-id, 

duc-ext-ind, 

cl-conn-attr-length, 

duc-descr-list}) 



Difterenl Transceiver 
at the same AP 
(Freq. changed) 



RRC forward handover ind 



Connection and Security Parameter 
and Options are Processed 



Redirect 

Connections 

to l\/IAC_new and 

update DUC_LIST 



RRC_radio_handover_rsp 



Associated_with_n e w_A PT_ 
Handover_completed_to_new_APT 



Diagram 35: Radio handover 



Table 46: RLC-HANDOVER-NOTIFY (OAP/OI\flT) 



RLC-HANDOVER-NOTIFY-ARG ::= SEQUENCE { 
ric-pdu-type RLC-SCH-PDU-TYPE 

handover-cause HANDOVER-CAUSE 



ap-id 


AP-ID OPTIONAL 


net-Id 


NET-ID OPTIONAL 


mac-id 


MAC-ID } 
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Table 47: RLC-HANDOVER-REQUEST 



RLC-HANDOVER-REQUEST-ARG ::= SEQUENCE { 



ric-pdu-type RLC-SCH-PDU-TYPE, 

ap-id-old AP-ID, -- AP-ID of old APT 

mac-id-old MAC-ID, - MAC-ID used in old APT 

net-id-old NET-ID 

due-established DUC-ESTABLISHED } 



Table 48: RLC-RADIO-HANDOVER-COMPLETE 



RLC-RADIO-HANDOVER-COMPLETE-ARG ::= SEQUENCE { 


ric-pdu-type 


RLC-LCH-PDU-TYPE 


mac-id-old 


MAC-ID 


ap-id-old 


AP-ID 


net-id-old 


NET-ID 


mac-id-new 


MAC-ID 


cl-id 


CL-ID 


duc-ext-ind 


DUC-EXT-IND 


cl-conn-attr-length 


INTEGER(0..31) 


duc-descr-list 


DUC-DESCR-LIST} 



The MT triggers handover by sending RLC_HANDOVER_REQUEST to the target AP, which shall then select the 
handover procedure (either radio or network handover). 

In case of a radio handover the AP shall respond with RLC_RADIO_HANDOVER_COMPLETE message to approve 
the request. The AP shall use RBCH for sending this message. MT shall update the unicast DUCs according to 
RLC_RADIO_HANDOVER_COMPLETE message before sending any Resource Requests. In this message the AP 
may either confirm the characteristics of the DUCs established in the previous radio cell or modify them. 

If not all DUCs, which the AP intends to maintain after handover, can be indicated in 

RLC_RADIO_HANDOVER_COMPLETE, the AP shall set the duc-ext-ind flag and address the remaining DUCs in 
subsequent DUC Modify. 

DUCs estabhshed in a previous radio cell, but addressed neither in RLC_RADIO_HANDOVER_COMPLETE nor in 
subsequent DUC Modify by the AP shall be considered by the MT as released. 

After radio handover AP, i.e. after sending RLC_RADIO_HANDOVER_COMPLETE, and MT, i.e. after receiving 
RLC_RADIO_HANDOVER_COMPLETE, shall trigger the reset actions for the on-going DUCs in acknowledged 
mode (see [5]) only, when the DUCs are modified in RLC_RADIO_HANDOVER_COMPLETE or DUC Modify. 

For the rejection of the Radio Handover, see clause 5.2.1.5. 

5.2.1 .3 Network Handover (OAP/OMT) 

A network handover may be carried out when an associated MT moves from one AP to another AP (see figure 3). Since 
the MT leaves the serving area of an RLC instance, a network handover involves also the CL and higher layers (HL). 
To maintain HL association and connections specific signalling via the fixed network may be needed. 
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MSC Network Handover 



1(11 



MT associated with old AP 




Force Handover 



HO Association 



HO_Linl<_Capability 



To l<en_NW_sig nailing 




Encryption_Startup 



Authentication 



Info Transfer 



Setu p_R ad io_Con n ection_m obi le_o rig in ated 



Handover_Completion 



Handover_Complete 



Diagram 36: Network Handover procedure 
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If the MT is still synchronized to the current AP, when triggering a handover to another (target) AP, it may notify the 
current AP by the RLC_HANDOVER_NOTIFY message, that it will perform a handover to another AP. 

The AP shall stop scheduling data to this MT after receiving RLC_HANDOVER_NOTIFY message. 

The MT may return within 255 frames from the frame, where the RLC_HANDOVER_NOTIFY message was sent 
(sending frame is number 0). If the MT returns to the old AP, the MT shall notify the old AP. In case data waits for 
transmission in the MT, it sends Resource Requests to the AP and, hence, informs the AP thereby about its presence. In 
case no data has to be transmitted, the MT shall trigger the MT Alive procedure. 



MSC HO_Association 

MT ENV 



MT RLC 



AP old RLC 



AP new RLC 



AP new ENV 



MT_associated_with_old_AP_ 
Handover_necessary 



RRC_handover_notify_req 



(RRC-HANDOVER-NOTIFY-AFIG ) 



RLC HANDOVER NOTIFY 



({handover-cause, 
ap-id, 
net-id, 
mac-idl )_ 



MT_synchronised_to_AP_new 



RRC_handover_req 



(RRC-HANDOVER-REQUEST-^g h^ANDOVER REOUEST 



T_nw_handover_request 



RRC handover association cnf 



rrc-h/!,ndover-association-arg; 

EstabishtheRLC 
Control Connection 



({ap-id -old, 
mac- b -old, 
net-id- old, 
due- established, 
mac-bO} ) 



RRC 



( RRC-HANDC(VER-ASSOCIATION-ARG) 
RLC HANDOVER ASSOCIATION 



( {mac-b-old, 

ap-id- old, 

net-id -old, 

mac-id -new}) 



RRC handover ind 



(RRC-HANDOVER-REQU^ST-ARG ) 
handover_association_rsp 



T handover association 



MT_pre_associated_with_new_AP 



Old MAC-ID, AP-ID, 
NET-ID are used as 
temporary Addre?s for 
theMT 



Establish the RLC 
Control Connection 



Diagram 37: Handover association procedure 



Table 49: RLC-HANDOVER-ASSOCIATION 



RLC-HANDOVER-ASSOCIATION-ARG ::= SEQUENCE { 


ric-pdu-type 


RLC-LCH-PDU-TYPE 


mac-id-old 


MAC-ID 


ap-id-old 


AP-ID 


net-id-old 


NET-ID 


mac-id-new 


MAC-ID } 
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The MT shall trigger handover by sending RLC_HANDOVER_REQUEST to the target AP, which shall then select the 
handover procedure (either radio or network handover). The AP shall respond with the 
RLC_HANDOVER_ASSOCIATION message to approve the request. 

In order to reject the RLC_HANDOVER_REQUEST, the AP shall respond with 

RCL_HANDOVER_REQUEST_NACK message. The AP shall use RBCH for sending these messages. After receiving 
RLC_HAND0VER_ASS0C1AT10N, the MT shall trigger the Handover (HO) link capability procedure. 



MSC HO„Link_Capability 

MT_ENV I 



MAC_ID_AssigiKd 



ACF_link_capabili ty_req 



(ACF-UNK -CAPABILITY -ARG ) 

T_link_cap ability 



RRC_handover_liiik_capabiIity_cnf 



{ RRC-HANDOVER-LINK-CAPABn.lTY-ACK-ARG) 



RLC_UNK_CAPABILrrY 



({profile-vid-list 
cl-vid-list, 
freq-band , 
rss- value, 
sipport64qam, 
direct-mode -cap, 
cyclic -prefix, 
sipport-fca, 
sipport-fsa, 
time-^p-ach-uplink, 
ho- cap, 
cc-ho-cap, 
duty- cycle, 
arq- delay- rx, 
arq- delay- tx, 

authentic ation-encryption-li.'J, 
dm- attributes) 



T_ha rd over_a.s sac iation 



ACF_Iink_c^ability_ind 



( ACF-UNK -CAPABILITY-ARG ) 



RRC_handover_fink_capability_i'sp 



( RRC-HANDOVER-UNK-CAPABILITY-ACK-ARG 
RLC_HANDOVER_LINK_CAPABIUTY_ACK 



( 



{ profile- vi d- list- (e lee ted , 

freq-band, 

rss-valie, 

apt -ad dress-length, 

support64qam, 

direct-mode- cap, 

dm-use -common-key, 

c>c lie-prefix, 

support- fc a, 

support- fsa, 

cc-ho-cap, 

arq-del^-rx, 

arq-delay-tx, 

a ut h- enc r-s elec ted, 

start-erKryption, 

start-authenticatioi, 

send-NW-Tolsn, 

start-DUC-set-up 

keep-connections, 

start-info- transfer, 

dm-attribites}) 



,/\ T_handover_link_capability_ack 



Liik_Agreed 



Diagram 38: Handover link capability procedure 
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Table 50: RLC-HANDOVER-LINK-CAPABILITY-ACK 



RLC-HANDOVER-LINK-CAPABILITY-ACK-ARG ::= SEQUENCE { 


ric-pdu-type 


RLC-LCH-PDU-TYPE 


profile-vid-list-selected 


PROFILE-VID-LIST 


freq-band 


FREQUENCY-BAND 


rss-value 


RSS-VALUE 


apt-address-length 


APT-ADDRESS-LENGTH 


support64QAM 


SUPPQRTED64QAM 


direct-mode-cap 


DIRECT-MODE-CAP 


dm-use-common-key 


DM-USE-CQMMON-KEY 


cyclic-prefix 


CYCLIC-PREFIX 


support-tea 


SUPPQRTED-FCA 


support-fsa 


SUPPQRTED-FSASUPPORTED-FSASUPPQRTED-FSA 


cc-ho-cap 


CC-HQ-CAP 


arq-delay-rx 


ARQ-DELAY 


arq-delay-tx 


ARQ-DELAY 


auth-encr-selected 


AUTH-ENCR-INFQ 


start-encryption 


START-ENCRYPTIQN 


start-authentication 


START-AUTHENTICATIQN 


send-NW-Token 


SEND-NW-TOKEN 


start-DUC-set-up 


START-DUC-SET-UP 


keep-connections 


KEEP-CONNECTIONS 


start-info-transfer 


START-INFO-TRANSFER 


dm-attributes 


DM-ATTRIBUTES OPTIONAL - (OAP/OMT) - } 



In the link capability procedure the MX shall provide its link capabilities to the AP using RLC_LINK_CAP ABILITY 
message. The AP shall respond with RLC_HANDOVER_LINK_CAPABILITY_ACK. Based on the 
RLC_HANDOVER_LINK_CAPABILITY_ACK a subset of the following procedures shall be executed: Encryption 
Startup, Authentication, Token NW Signalling, Info Transfer, Setup Radio Connection mobile originated. The order of 
the procedures and allowed combinations are presented in diagram 36. How the keep-connections and 
start-DUC-set-up parameters shall be interpreted is shown in table 51. 

Table 51 : Definition of interpretation for keep-connections and start-DUC-set-up parameters 



Parameter value for 
keep-connections 


Parameter value for 
start-DUC-set-up 


Comment 


donot-keep-conn 


start-setup 


The MT shall initiate Setup Radio Connection 
mobile originated 


keep-connections 


donot-start-setup 


The MT shall continue to use the DUCs 
established at the earlier AP. 


donot-keep-conn 


donot-start-setup 


used if AP initiates DUC setup or DUC 

information is included in 

RLC NETWORK HANDOVER COMPLETE 


keep-connections 


start-setup 


Invalid combination 



Regardless of which procedures are selected, the AP shall complete the entire network handover procedure, by 
transmitting the RLC_NETWORK_HANDOVER_COMPLETE message. In this message the AP may either confirm 
the characteristics of the DUCs established in the previous radio cell or modify them, only in the case DUCs have not 
already been negotiated during the Network Handover, i.e. by Setup Radio Connection mobile originated or when the 
keep-connections parameter indicates that connections shall be kept. 

If not all DUCs, which the AP intends to maintain after handover, can be indicated in 

RLC_NETWORK_HANDOVER_COMPLETE, the AP shall set the duc-ext-ind flag and address the remaining DUCs 
in subsequent DUC Setup. This mechanism may also be used to establish DUCs by the AP. 

DUCs estabhshed in a previous radio cell, but addressed neither in RLC_NETWORK_HANDOVER_COMPLETE nor 
in subsequent DUC Setup by the AP shall be considered by the MT as released. 

After network handover AP and MT shall trigger the reset actions for the on-going DUCs in acknowledged mode 
(see TS 101 475 [5]). 
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MSC Token_NW_signalling 

MT ENV MT RLC 



ACF_nw_signalling_hando\ier_req 



AP new RLC 



AP new ENV 



AP old ENV 



Link_Agreed 



(RRC-NW-SIGNALLING-H/iNDOVER-ARG ) 

RLC NW SIGNALLING HAND0VER 



T_nw_s ignal lingLhandover 



RLC NW 



AGF_nw_signalling_handover_cnf 



RRC-NW-SIGNALLING-hlANDOVER-AGK-ARG) 



({mt-token-auth-encr} ) 



( RRC-NW-SIGNALLIN0 
SIGNALLING HANDOVER ACK 



( {ap-token-auth-ena}) 



T handover link 



AGF_nw_signalling_har doverjnd 



(RRC-NW-SIGNALLING 



( 
ACF_nw_:3ignalling_handover_rsp 



HANDOVER- ACK-ARG) 



T_nw_signalling 



.capability_ack 



HANDOVER-ARG 
ho_info_req 



({mac-id -old} ) 
ho_info_rsp 



{ap-token-auth-ena, 

DHage, 

dh-seaet}) 



handover ack 



Associated to new AP 



Diagram 39: Token network signalling procedure 



Table 52: RLC-NW-SIGNALLING-HANDOVER 



RLC-NW-SIGNALLING-HANDOVER-ARG ::= SEQUENCE { 



ric-pdu-type RLG-LCH-PDU-TYPE 

mt-token-auth-encr MT-TOKEN-AUTH-ENCR} 



Table 53: RLC-NW-SIGNALLING-HANDOVER-ACK 



RLC-NW-SIGNALLING-HANDOVER-ACK-ARG ::= SEQUENCE { 



rIc-pdu-type RLC-LCH-PDU-TYPE } 

ap-token-auth-encr AP-TOKEN-AUTH-ENCR 
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When a MT performs a handover it may send the RLC_NW_SIGNALLING_HANDOVER message, depending on 
send-NW-token in HANDOVER-LINK-CAP ABILITY-ACK. The MT calculates 

MD5 (tokenlauthentication-encryption-listlauth-encr-selected) based on the earlier received token, the earlier sent 
authentication-encryption-list and the received auth-encr-selected and sends the result to the AP. 

NOTE: With support of the fixed network, the new AP can contact the old AP directly and verify the continuity. 

The token, DH age and DH secret shall be transferred from the old AP to the new AP during network handover. The 
procedures for the information transfer via the fixed network are out of the scope of the present document. 

The new AP shall do the following for security purposes: 

1) Contact the old AP, presenting the old MAC ID of the MT and fetching the following information: 

- Token, the same one was sent to the MT by the old AP in the RLC_HO_INFO_DISTRIBUTION message; 

DHsecret, which equals g''^ mod n, the result of the last Diffie-Hellman exchange carried out in the 
encryption startup procedure; 

DHAge, how long time the DHsecret has been used. 

2) Calculate MD5(tokenlauthentication-encryption-listlauth-encr-selected) and compare the result with the one 
received in RLC_NW_SIGNALLING_HANDOVER. If the two hash values are not equal, reject the MT's 
handover request. 

3) Calculate the new unicast key SSK as described in clause 5.1.2.5.4. 

4) Send back the RLC_NW_SIGNALLING_HANDOVER_ACK message, encrypted with the new SSK (if 
encryption is used). The AP calculates MD5(tokenlauthentication-encryption-listlauth-encr-selected) based on 
the token received from the old AP, earlier received authentication-encryption-list and sent auth-encr-selected 
and sends the result to the MT. 

The MT shall calculate the new SSK (see clause 5.1.2.5.4) and verify that the received information in the 
RLC_NW_SIGNALLING_HANDOVER_ACK message is the same as used for the calculation of the 
RLC_NW_SIGNALLING_HANDOVER message. 
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5.2.1.4 



Token distribution for Network Handover 



The transfer of the token shall be done while the MT is associated to the current AP. The current AP sends the message 
to the MT. It contains a token encrypted with the unicast key (RLC_HO_INFO_DISTRIBUTION). The MT decrypts 
the token and stores it for later use. It also sends an acknowledgement back to the old AP. 



MSC Network Handover Info Distribution 



MT ENV 



MT RLC 



AP RLC 



AP ENV 



MT associated with AP 



ACF ho info distribution ind 



RRC-HO-INFO-DISTRIBUTION-/^RG) 
ACF_tol<en_distribution_rsp 



( RRC 
RLC HO INFO DISTRIBUTION 



({token}) 



(RRC-HaiNFO-DISTRIBUTION-ACK-ARG ) 

RLC HO INFO DISTRIBUTION ACK 



({mac-id} ) 



T_handover_link_capability_ack 
T_key_exch an ge_a p 
T_authentication_ack 
T_nw_signalling_handoveri ack 



ACF_ho_info_distribu1ion_req 



HO-INFO-DISTRIBUTION-ARG) 



T ho info distribution 



AC^ 



ho info distribution cnf 



(RRC-HO-INFO-DISTRIBUTION-ACK-ARG 



MT associated with AP 



Diagram 40: Network handover info distribution 
Table 54: RLC-HO-INFO-DISTRIBUTION 



RLC-HO-INFO-DISTRIBUTION-ARG ::= SEQUENCE { 
ric-pdu-type RLC-LCH-PDU-TYPE 
token TOKEN } 



Table 55: RLC-HO-INFO-DISTRIBUTION-ACK 



RLC-HO-INFO-DISTRIBUTION-ACK-ARG ::= SEQUENCE { 
rIc-pdu-type RLC-SCH-PDU-TYPE 
mac-id MAC-ID } 
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The Token should be a random value. The Token shall be used for the two following purposes: 

1) to show that the MT is really the one that made a network handover from the old AP to the new AP; 

2) to allow the MT and the new AP to calculate a new SSK based on the Token. 

NOTE: The function needs a random number (see bibliography, "Applied cryptography Second Edition" and 
"Randomness Recommendations for Security" for further information about this subject). 

NW Handover Info Distribution shall be executed after association and network handover to keep the token up-to-date. 



MSC Handover_Completion 

MT ENV MT RLC 



AP new RLC 



AP new ENV 



Associated with new AP 



RLC NEITWORK HANDOVER COMPLETE 



T_connect_acl< 

TJ inl<_capabil i1y_acl< 

T_l<ey_exchange_ap 

T_au th en ticatio n_acl< 

T_(Jm_common_key_distr_acl< 

T info acl< 



T_nm_signallincLhandover_acl< /^ 

RRC_network_handover_complete_cnf 

-^ 

( RRC-NETWORK-HANDOVER-COMPLETE-ARG) 



RRC_hetwork_handover_complete_rsp 

■< 

( RRC-NETWORK-HANDOVER-COMPLETE-ARG) 



{cl-id, 

duc-ext-ind, 

cl-conn-attr-length, 

duc-descr-list}) 



T_nw_handover_complete 



Handover_completed_to_new_AP 



Diagram 41 : Handover Completion procedure 



Table 56: RLC-NETWORK-HANDOVER-COMPLETE 



RLC-NETWORK-HANDOVER-COMPLETE-ARG : 


:= SEQUENCE { 


ric-pdu-type RLC-LCH-PDU-TYPE 




cl-id CL-ID 




duc-ext-ind DUC-EXT-IND 




cl-conn-attr-length INTEGER(0..31 ) 




duc-descr-list DUC-DESCR-LIST } 
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5.2.1.5 Handover Rejection 

The rejection of the Radio and Network Handover procedures shall follow the next two rules: 

1 . If the AP does not accept the RLC_HANDOVER_REQUEST message, the AP shall respond with the 
RLC_HANDOVER_REQUEST_NACK message. 

2. After the MT has a MAC ID, a possible rejection shall be done by sending RLC_DISASSOCIATION message. 
Both the MT and AP shall use this message for this purpose. 

NOTE: Because of varying radio link conditions, the Disassociation may happen implicitly, see clause 5.1.3. 

Table 56a: RLC-HANDOVER-REQUEST-NACK 



RLC-HANDOVER-REQUEST-NACK-ARG ::= SEQUENCE { 



ric-pdu-type RLC-SCH-PDU-TYPE 
ap-id-old AP-ID - AP-ID of old APT 
mac-id-old MAC-ID - MAC-ID used in old APT 
net-id-old NET- ID) 



5.2.1 .6 Forced Handover (AP initiated handover) (OAP/OMT) 

APs may initiate HO capable MTs to perform forward handover by using RLC_FORCE_HANDOVER. The AP shall 
make sure that the MT is HO capable. The AP shall stop scheduling data to the MT after sending 
RLC_FORCE_HANDOVER message. 

- If the return-flag value is set to zero, the MT shall respond with RLC_FORCE_HANDOVER_ACK and shall 
not return to the current AP to continue operation with the old association. When the 
RLC_FORCE_HANDOVER_ACK is received by the AP, it shall disassociate the MT without sending the 
RLC_DISASSOCIATION message. 

- If return-flag is set to one, MTs shall respond with RLC_FORCE_HANDOVER_ACK. The MT shall not return 
to operate with old association after 255 frames after the frame the RLC_FORCE_HANDOVER_ACK was 
received by the AP (the receiving frame is number 0). When returning to the old AP, the MT shall continue 
operation with the AP by sending RLC_MT_ALIVE, Resource Request or RLC_HANDOVER_NOTIFY. 
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MSC Force Handover 



MT ENV 



MT RLC 



AP RLC 



AP ENV 



MT_associated_with_olcl_AP_Handover_necessary 



RRC force handover ind 



RRC-FORCE-HANDOVER-ARG) 
RRC_force_handover_rsp 



RLC FORCE HANDOVER 



( {return -flag, 

force-handover -cause, 

frequency-index, 

ap-id, 

net- id}) 



(RRC-FORCE-HANDOVER-ACK-^RG 

RLC FORCE HANDOVER ACK 



RRC_force_handover_req 



( RRC-FORCE-HANDOVER-ARG) 



T force handover 



RRC_force_handover_cnf 

* 

(RRC-FORCE-HANDOVER-ACK-ARG 



Forced Handover Initiated 



Diagram 42: Forced handover procedure 



Table 57: RLC-FORCE-HANDOVER 



RLC-FORCE-HANDOVER-ARG ::= SEQUENCE ■ 



ric-pdu-type 

return-flag 

force-handover-cause 

frequency-index 

ap-id 

net-id 



RLC-SCH-PDU-TYPE 

RETURN-FLAG 

FORCE-HANDOVER-CAUSE 

FREOUENCY-INDEX 

AP-ID 

NET-ID} 



Table 58: RLC-FORCE-HANDOVER-ACK 



RLC-FORCE-HANDOVER-ACK-ARG ::= SEQUENCE { 



rIc-pdu-type 
mac-id 



RLC-SCH-PDU-TYPE 
MAC-ID } 



5.2.2 Dynamic Frequency Selection 



5.2.2.1 



Introduction to DFS 



The Dynamic Frequency Selection (DFS) in HL/2 systems shall result in equal usage of available frequencies under the 
consideration of avoiding the interference of other devices using the same spectrum [12]. The interference may arise 
from neighbouring HL/2 networks using the same frequency or non-HL/2 devices in the frequency band. Every AP 
should collect measurement results and choose an operating frequency based on the measurement results. The decision 
may be done independently of other APs. 
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5.2.2.2 DFS algorithm 

The DFS algorithm is out of the scope of the present document. 



5.2.2.3 



DFS protocol 



The AP may request any associated MTs to measure and report the measurements. The MT shall perform the 
measurements and after the measurement it shall report the results to the AP. 

A MT may also do self-initiated measurements and request to report the results to the AP. The AP may then poll the 
MT for the result or may ignore the request. The implementation of the RLC_MT_INITIATED_REPORT_REQUEST 
is optional for the MT, but mandatory for the AP. 



MSC DFS Measurements 



1(1) 



Active Mode 



change_frequency 



dfs_mt_init_ 
_report_req 



dfs_measurement_ 
_complete_request 




dfs_ap_absence 



dfs_measurement_ 
_short_request 



dfs_measurement_ 
_percentiles_request 



dfs_report_complete 




dfs_report_percentiles 



Diagram 43: DFS measurements 
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5.2.2.4 



DFS measurements 



APs and MTs shall be able to perform measurements to support DFS, namely RSS measurements at a given frequency. 
APs and MTs shall be able to decode possible BCH transmissions of other APs at a given frequency. 

The measurements in the AP are out of scope of the specification. 

When the AP is switched on, it shall measure on all frequencies it is permitted to use. 

5.2.2.4.1 AP Measurement Procedure 

When the AP makes measurements and is not able to transmit, it shall use AP Absence. 

NOTE 1: AP should disturb sleeping MTs as little as possible. This can be handled by making the measurement 
between MAC broadcast sleep group frames. 

The maximum AP Absence period shall be 15 frames. The AP shall keep its frame cycle during AP Absence. 

NOTE 2: The three shortest sleeping periods for MTs are 2, 4 and 8 frames. The MT that has one of these short 

sleeping periods, may lose 1 to 8 expected BCHs during AP Absence period. The MT can, however, hear 
the AP_ABSENCE message during the MAC broadcast sleep group frame. 



MSC dfs_ap_absence 

MT ENV 



MT RCP 



AP RCP 



AP ENV 



Active Mcxde 





RRC_ap_absence_ind 


RLC_AP_ABSENCE 


RRC_ap_alDsence_req 






( RRC-AP-ABSENCE-ARG) 






( {first-mac-frame, 
last-mac-frame}) 






( RRC-AP-ABSENCE-ARG) 





Active Mode 



Diagram 44: DFS AP absence procedure 



Table 59: RLC-AP- ABSENCE 



RLC-AP-ABSENCE-ARG ::= SEQUENCE { 



ric-pdu-type 

first-mac-frame 

last-mac-frame 



RLC-SCH-PDU-TYPE 
FIRST-MAC-FRAME 
LAST-MAC-FRAME } 
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5.2.2.4.2 



MT Measurement Procedures 



Three measurement types are defined for a MT: short, percentiles and complete. All of the measurement requests shall 
be sent as unicast messages only. 

Short: at the given time and frequency, MT shall scan for BCH. If a BCH is found it shall be decoded and its RSS shall 

be measured. 



MSC dfs_measurement_short_request 

MT_ENV I I MT_RCP 



AP_RCP 



AP ENV 



ActiveMode 



RRC 



RLC_DFS_MEASUREMENT_SHORT_REQUEST 



dfs_measurement_short_request_ind 



RRC-DFS-MEASUREMENT-SHORT-REQUEST-ARG) 



RRC_dfs_measurement_short_request_req 



( RRC-DFS-MEASUREMENT-SHORT-REQUEST-ARG) 



{frequency- index, 

use-omni-antenna, 

start-of-measurement, 

measurement-window, 

maxim urn -age-of-bch-measure me nt}) 



Active_Mode 



Diagram 45: DFS short measurement request 



Table 60: RLC-DFS-MEASUREMENT-SHORT-REQUEST 



RLC-DFS-MEASUREMENT-SHORT-REQUEST-ARG ::= SEQUENCE { 



ric-pdu-type 

frequency-index 

use-omni-antenna 

start-of-measurement 

length-of-measurement 



RLC-LCH-PDU-TYPE 

FREQUENCY-INDEX 

USE-OIVINI-ANTENNA 

START-OF-IVIEASUREIVIENT 

IVIEASUREIVIENT-WINDOW 



maximum-age-of-bcii-measurement MAXIMUM-AGE-OF-BCH-IVIEASUREIVIENT } 



Percentiles: at the given time and frequency, the MT shall collect RSS samples with equal distance 8 |is. 
NOTE: No decoding of BCH is done for percentiles measurement. 
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MSC dfs_measurement_percentiles_request 

I MT_ENV I I MT_RLC I 



AP_RLC 



Active Mode 



RLC_DFS_MEASURE\/IENT_PERCENTILES_REQUEST 



measurement_percentiles_request_ind 



RRC_dfs. 

rrc-dfs-4easurei\|ient-percentiles-request-arg) 



RRC_dfs_"neasurement_percentiles_request_req 



( RRC-DFS-MEASUREMENT-PERCENTILES-REQUEST-ARG) 



( {frequency-index, 

use-omni-antenna, 

start-of-measurement, 

measurement-window, 

rss-index-list} 

) 



Active Mode 



Diagram 46: DFS percentiles measurement request 



Table 61 : RLC-DFS-MEASUREMENT-PERCENTILES-REQUEST 



RLC-DFS-MEASUREMENT-PERCENTILES-REQUEST-ARG : 


:=SEOUENCE{ 


ric-pdu-type 


RLC-LCH-PDU-TYPE 




frequency-index 


FREQUENCY-INDEX 




use-omni-antenna 


USE-OMNI-ANTENNA 




start-of-measurement 


START-OF-MEASUREIVIENT 




measurement-window 


MEASUREMENT-WINDOW 




rss-index-list 


RSS-INDEX-LIST} 





Complete: a combination of the short and percentiles measurements, where at the given time and frequency BCH shall 
be decoded and RSS measurement on the BCH shall be performed and the RSS samples shall be collected. 



MSC dfs_measurement_complete_request 



MT ENV 



MT_RLC 



AP_RLC 



AP ENV 



Active_Mode 



RRC dfs 



rlc_dfs_measurement_complete_request 



.measurement_comp!ete_request_ind 



RRC-DFS-MEASUREMENT-COMPLETE-REQUEST-ARG) 



RRC_dfs_ 
( RRC-DFS-MEASUF EMENT-COMPLETE-REQUEST-ARG) 



{frequency-index, 

use-omni-antenna, 

start-of-measurement, 

measurement-window, 

aximum-age-of-bch-measurement, 

rss-index-list}) 



.measu rem e nt_co mplete_req u est_req 



Active Mode 



Diagram 47: DFS complete measurement request 
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Table 62: RLC-DFS-MEASUREMENT-COMPLETE-REQUEST 



RLC-DFS-MEASUREMENT-COMPLETE-REQUEST-ARG ::= SEQUENCE { 


ric-pdu-type 


RLC-LCH-PDU-TYPE 


frequency-index 


FREQUENCY-INDEX 


use-omni-antenna 


USE-OMNI-ANTENNA 


start-of-measurement 


START-OF-MEASUREMENT 


measurement-window 


MEASUREMENT-WINDOW 


maximum-age-of-bch-measurement 


MAXIMUM-AGE-OF-BCH-MEASUREMENT 


rss-index-list 


RSS-INDEX-LIST} 



Each RSS sample measurement shall follow the requirements in [4]. 

The measurement requests described above are sent from AP to MT, but MT may also ask AP to send the request. In 
this case, the AP shall answer MT with an ACK. The ACK shall contain a flag stating whether the AP is going to send a 
request or not. 



MSC dfs_mt_init_report_req 

MT ENV MT RCP 



AP RCP 



AP ENV 



Active Mode 



RRC_dfs_mt_init_report_req 



(RRC-DFS-MT-INIT-REPORT-F|EQUEST-ARG ) 

RLC DPS MT INIT REPORT REQUESt 



T_d f s_mt_i ni t_re po rt 



RRC-DFS-MT-INIT-REPOR 



RRC_df s_mt_in it_report_ind 



{{measurement-type, 

frequency-index, I ^ 

adjacent-ch-interference, (RRC-DFS-MT-INIT-REPORT-REQUEST-ARG 
mac- id} ) 

RRC_dfs_mt_i nit_report_acl<_rsp 



( RRC-DFS-MT-INIT-REP0RT-REQUEST-ACK-ARC5) 

RLd Dps MT IN FT REPORT REOUEST ACK 



( reporting-intialized) 
RRC_dfs_mt_init_report_ack_(bnf 

-REOUEST-ACK-ARG) 

Active Mode 



Diagram 48: DFS MT init report request procedure 
(OMT Optional for the AP to send a request after receiving the message) 



Table 63: RLC-DFS-MT-INIT-REPORT-REQUEST 



RLC-DFS-MT-INIT-REPQRT-REQUEST-ARG ::= SEQUENCE 



rIc-pdu-type 

measurement-type 

frequency-index 

adjacent-ch-interference 

mac-id 



RLC-SCH-PDU-TYPE 
MEASUREMENT-TYPE 
FREQUENCY-INDEX 
ADJACENT-CH-INTERFERENCE 
MAC-ID } 
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Table 64: RLC-DFS-MT-INIT-REPORT-REQUEST-ACK 



RLC-DFS-MT-INIT-REPORT-REQUEST-ACK-ARG ::= SEQUENCE { 
ric-pdu-type RLC-SCH-PDU-TYPE 
reporting-initialized REPORTING-INITIALIZED } 



5.2.2.4.2.1 Measurements on other frequencies 

When the AP needs measurements on other frequencies than the one it is currently using, the AP may request one or 
more MTs to do the measurements. In order to do that, the AP shall send one of the three measurement requests. 

The measurement procedure on a currently not used frequency is described below. 

1) The MT shall measure RSSO [4] for the last_own_bch_rss_level from the frame previous to the frame number 
start-of-measurement. 

2) The MT shall start to tune to the specified frequency /from the beginning of the MAC frame that is announced 
with start-of-measurement. 

NOTE 1 : Tuning time is not included in the measurement-window. 

3) Depending on the measurement type, the measurement procedure shall be the following: 

Short: the MT shall search for BCH of other interfering APs for at most for 5 frames (i.e. measurement 
window larger than 5 is not applicable). If found the BCH shall be decoded and RSSO [4] shall be measured 
on the BCH. If several BCHs are found the strongest RSSO value should be stored for reporting. The MT also 
stores part of the BCH content for reporting. See description of corresponding measurement reports. 

Percentiles: consecutive RSSl samples [4] with distance 8 )J.s shall be collected during the specified 

measurement-window. 

Complete: the MT shall tune to the new frequency and search for BCH of other interfering APs for at most 5 
frames. If found the BCH shall be decoded and RSSO [4] shall be measured on the BCH. If several BCHs are 
found the strongest RSSO value should be stored for reporting. Also parts of the decoded BCH content is 
stored for reporting. See description of corresponding measurement report. Also for the remaining time of the 
measurement window consecutive RSSl samples [4] with distance 8 )is shall be collected. The order of these 
two measurement phases is out of scope of the present document. 

4) The MT shall then tune to the original frequency /^^ The retuning time is not included in the 

measurement-window. 

5) MT shall report the requested measurement results to the AP. The report shall be available at the latest 5 frames 
after the return to the current frequency. 
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RLC_DFS_MEASUREMENT_SHORT_ 
REQUEST or 

RLC_DFS_MEASUREMENT_PRECENTILES_ 
REQUEST or 

RLC_DFS_MEASUREMENT_COMPLETE_ 
REQUEST 

Store the last own BCH RSSO 



Tuning shall be ready and MT starts 
measurement on requested frequence 



The report shall be ready to be sent 1 

tuning frame and 5 frames after 

Measurement Window ending point 



MT starts tuning to 
requested frequency 




MT starts tuning back to its own 
frequency and resynchronises to the API 



• • • 



-start-of-measuremem 



,(_J^Max J 
'^^Ims^ 



( • I 



L Max J 
P"lms^ 

L measurement-window J 

r^ (0-63 frames) ^ 

Measurement Time J 

{measurement-window+ 2 tuning frames) \ 

m-(start-of-measurement+ measurement-window+ 2 tuning frames+ 5 frames)-W 

Figure 4: The measurement on other frequencies 

The start-of-measurement value is counted from the frame, where the message was received (i.e. next frame is frame 0). 

Start-of-measurement shall not be smaller than 2 MAC frames i.e. the AP can not expect the MT to start tuning to the 
new frequency until two frames after the measurement request was transmitted. The example above depicts the scenario 
when start-of-measurement = 2. 

The AP should not schedule any data to the measuring MT during the measurement time. The measurement time shall 
be from the start-of-measurement frame (belonging to measurement): 

measurement- window + 2 frames. 

NOTE 2: The 2 frames extra are for tuning and retuning time. 



5.2.2.4.2.2 



Measurements on used frequency 



When the AP needs measurements on the used frequency to be done by MT, the AP shall send one of the three 
measurement requests. The procedures shall be according to A or B. 

Procedure A: 

If the AP sends the RLC_DFS_MEASUREMENT_COMPLETE_REQUEST or 

RLC_DFS_MEASUREMENT_SHORT_REQUEST, the AP shall set the empty space for measurements by 
transmitting the RLC_AP_ABSENCE message and entering into the AP_Absence. 

The measurement-window shall be set in the request so that it defines a coarse interval during which the MT can expect 
to perform its measurement request. The real measurement is then triggered by the RLC_AP_ABSENCE message and 
the MT uses the beginning of the AP_ABSENCE interval as its start_of_measuring. The AP Absence interval should 
defined be within the measurement window. 
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The measurement procedure is described below: 

1) The MT shall measure RSSO [4] for the last_own_bch_rss_level from the frame previous to the frame number 
start-of-measurement. 

2) Depending on the measurement type, the measurement shall be the following: 

Short: the MT shall search for BCH of other interfering APs during the AP Absence. If found the BCH shall 
be decoded and RSSO [4] shall be measured on the BCH. If several BCHs are found the strongest RSSO value 
should be stored for reporting. The MT also stores parts of the BCH content for reporting. 

- Complete: the MT shall search for BCH of other interfering APs during the AP Absence. If found the BCH 
shall be decoded and RSSO [4] shall be measured on the BCH. If several BCHs are found the strongest RSSO 
value should be stored for reporting. The MT also stores parts of the BCH content for reporting. Also for the 
remaining time of the Absence period consecutive RSSl samples [4] with distance 8 )J.s shall be collected. 
The order of these two measurement phases is out of scope of the present document. 

3) MT shall report the requested measurement results to the AP. The report shall be available at the latest 5 frames 
after end of measurement window. 



RLC_DFS_MEASUREMENT_SHORT_REQUEST 
RLC_DFS_MEASUREMENT_COMPLETE_REQU 
EST 



RLC AP ABSENi 



Store the last own BCH 
RSSO 



AP Absence starts 
(first frame after "last- 
mac-frame") 




MT ready to send the 
report 



AP Absence- 



- Start-of-measurement -► 



-Measurement Window - 



^—5 frames - 



-MeasurementTime- 



Figure 5: Short or Complete measurement on used frequency 

The start-of-measurement value is counted from the frame, where the message was received (i.e. next frame is frame 0). 

Start-of-measurement shall not be smaller than 2 MAC frames, i.e. the AP can not expect the MT to start measuring 
until two frames after the measurement request was transmitted. The example above depicts the scenario when 

start-of-measurement = 2. 

The AP shall make sure that the MT is notified of the start of the absence period at least 2 frames prior to the start of the 
actual measurement interval (i.e. also this notification shall also be performed at least two frames beforehand). 

If the MT for some reason doesn't succeed in finding an AP Absence interval within the measurement-window it shall 
neglect the corresponding measurement request. 

The RLC_AP_ABSENCE message pointing to the measurement shall be sent before or in the same frame with the 
measurement request. 

NOTE: The AP should not schedule any data to the measuring MT during the measurement time. The 
measurement time shall be from the start-of-measurement frame (belonging to measurement): 
measurement-window 
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Procedure B: 

If the AP sends the RLC_DFS_MEASUREMENT_PERCENTILES_REQUEST there are two possibiHties (Bl or B2). 
Both shall be supported by the MT. 

Bl: If the AP requires the MT to measure only the empty spaces of the frame, the AP shall indicate them by using FCH 
IE for indicating empty parts in the MAC frame [5]. 

The FCH IE for the empty parts shall not be scheduled earlier in the MAC frame than what is given by the minimum 
time between ACH and first uplink phase [5]. 

The AP shall use the same technique as described in A. That is it only gives a coarse measurement window description 
in the measurement request and set the start-of-measurement to point out the frame, where the scheduling of the empty 
slots is expected to be started. 

The measurement procedure is described below. 

1) The MT shall measure RSSO [4] for the last_own_bch_rss_level from the frame previous to the frame number 
start-of-measurement. 

2) The MT shall collect the RSSl samples [4] with distance 8 )is in all available empty spaces. 

3) MT shall report the requested measurement results to the AP. The report shall be available at the latest 5 frames 
after end of measurement window. 



RLC_DFS_MEASUREMENT_PERC 
ENTILES REQUEST 



Store the last own 
BCH RSSO 



Empty parts = actual 

measurement 

intervals 




MT ready to send 
the report 



Start-of- 
measurement 



-measurement-window - 



-5 frames- 



Figure 6: Percentiles measurement on used frequency 

The start-of-measurement value is counted from the frame, where the message was received (the next frame is frame 
number 0). 

Start-of-measurement shall not be smaller than 2 MAC frames i.e. the AP can not expect the MT to start measuring 
until two frames after the measurement request was transmitted. 

The AP should not schedule any data to the measuring MT during the measurement time. The measurement time shall 
be from the start-of-measurement frame (belonging to measurement): measurement-window. 

B2: the AP may also use AP Absence procedure as in case A. The AP is supposed not to use B 1 and B2 at the same 
time for a certain percentile measurement. 



5.2.2.4.3 



MT measurement processing 



5.2.2.4.3.1 Measurement processing (field strength measurement) 

The RSS statistics specified in the measurement request shall be calculated and reported to the AP. 

5.2.2.4.3.2 Measurement processing (field strength measurement and BCH decoding) 

In addition to the RSS measurements described above, the MT may also be requested to decode the BCH of the 
measured frequency. In this case, the RSSO [4] of the BCH and parts of the BCH content shall also be reported to the 
AP. 
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5.2.2.4.3.3 



Indication of measurement time 



When the AP requests an MT to measure interference on the currently used frequency according to ahernative B the AP 
shall indicate in the FCH where in the MAC frames the MT shall measure (i.e. where empty space is located). This shall 
be done by using a special information element (IE) type for this purpose, defined in [5]. 



5.2.2.4.4 



Calculation of RSS statistics (informative) 



After the MT has collected RSS samples, statistical values are calculated by the MT and reported to the AP. The 
statistical values are percentiles of the interference. The percentile calculation is described below. 

The only possible RSS values are [0, -1, -2, ..., -31] dB, as defined in [4]. 

NOTE: The RSSl are relative measurements that give the message outside of the BCH relative to a value 
RSS_REF, as described in the PHY reference mentioned. 

Thus, the percentiles can be calculated in the following way: 

1) each RSS sample is placed in a bin, where the bins have values [0, -1, -2, ..., -31]; 

2) after all samples have been collected (250 samples/MAC frame) the value M is found, where M equals the 
maximum value m (dB) such that < x % of the samples have an RSS value < m; 

3) the value M equals the x % percentile. 

EXAMPLE: Assume that there are the following RSS samples collected: 



RSS value (bin) 


No of samples 












-28 


4 


-29 


5 


-30 


7 


-31 






When 5 % percentile out of total 250 samples is needed to be calculated, the result will be M = -29, since 12 samples 
(4,8 %) lie in the bins -31 to -29 and 16 samples (64 %) He in the bins -31 to -28. 
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5.2.2.5 



DFS measurement reports 



MT shall report the RSS distribution at a given frequency relative to the latest performed RSSO measurement on the 
currently used frequency, which is also included in the message. If the MT decodes the BCH channel of another AP, it 
shall also include the following fields of the BCH, if it is requested by the AP; AP ID, Net ID, AP Tx power level. 
Traffic load. In addition the MT shall report RSSO of the decoded BCH. 



MSC dfs_report_short 



MT ENV 



MT RCP 



RRC_clfs_report_short_rsp 



(RRC-DFS-REPORT-SHORT-ARG 



AP RCP 



AP ENV 



Active Mode 



RCP DFS REPORT SHORT 



{{frequency-index, 
omni-antenna-used, 
age-of-measurement, 
I ast-o wn- bch -rx-le vel , 
bch-found, 
traffic-load, 
ap-id, 
tx-level, 
net-id, 
bch- rx-le vel} 



RRC_dfs_report_short_cnf 



(RRC-DFS-REPORT-SHORT-ARG 



Active Mode 



Diagram 49: DFS short report 



Table 65: RLC-DFS-REPORT-SHORT 



RLC-DFS-REPORT-SHORT-ARG ::= SEQUENCE { 


ric-pdu-type 


RLC-LCH-PDU-TYPE 


frequency-index 


FREQUENCY-INDEX 


omni-antenna-used 


OMNI-ANTENNA-USED 


age-of-measurement 


AGE-QF-MEASUREMENT 


last-own-bch-rx-level 


LAST-OWN-BCH-RX-LEVEL 


bch-found 


BCH-FOUND 


traffic-load 


TRAFFIC-LOAD 


ap-id 


AP-ID 


tx-level 


TX-LEVEL 


net-id 


NET-ID 


bch-rx-level 


BCH-RX-LEVEL } 
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MSC dfs_report_percentiles 

MT ENV MT RCP 



AP RCP 



AP ENV 



Active Mode 



RRC_dfs_report_percenti es_rsp 



(RRC-DFS-REPORT-PERCENTILEp-ARG ) 

RCP DFS REPORT PERCENTILES 



({frequency-index, 
omni-antenna-used, 
last-own -bch-rx- leve I , 
number-of-samples, 
rss-index-list, 
rss-statistics-list} ) 



Active Mode 



RRC_d1s_report_percentiles_cnf 



(RRC-DFS-REPORT-PERCENTILE&ARG 



Diagram 50: DFS percentiles report 



Table 66: RLC-DFS-REPORT-PERCENTILES 



RLC-DFS-REPORT-PERCENTILES-ARG ::= SEQUENCE { 


ric-pdu-type 


RLC-LCH-PDU-TYPE, 


frequency-index 


FREQUENCY-INDEX 


omni-antenna-used 


OMNI-ANTENNA-USED 


last-own-bcli-rx-level 


LAST-OWN-BCH-RX-LEVEL 


number-of-samples 


NUMBER-OF-SAMPLES 


rss-index-list 


RSS-INDEX-LIST 


rss-statistics-list 


RSS-STATISTICS-LIST } 
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MSC dfs_report_complete 

MT ENV MT RCP 



AP RCP 



AP ENV 



Active Mode 



RR C_dfs_report_complete_rsp 



(RRC-DFS-REPORT-COMPLETE-ARG ) 

RCP DPS REPORT COMPLETE 



{{frequency-index, 

omni-antenna-used, 

age-of- measurement, 

last-own-bch-rx-level, 

number -of -samples, 

bch-found, 

traffic- load, 

ap-id, 

tx-level, 

net-id, 

bch-rx-level, 

rss-ind ex-list, 

rss-statistics-list} 



R RC_dfs_report_complete_cnf 



(RRC-DFS-REPORT-COMPLETE-AF!G 



Active Mode 



Diagram 51 : DFS complete report 



Table 67: RLC-DFS-REPORT-COMPLETE 



RLC-DFS-REPORT-COMPLETE-ARG ::= SEQUENCE { 


ric-pdu-type 


RLC-LCH-PDU-TYPE 


frequency-index 


FREQUENCY-INDEX 


omni-antenna-used 


OMNI-ANTENNA-USED 


age-of-measurement 


AGE-QF-MEASUREMENT 


last-own-bch-rx-level 


LAST-QWN-BCH-RX-LEVEL 


number-of-samples 


NUMBER-QF-SAMPLES 


bch-found 


BCH-FQUND 


traffic-load 


TRAFFIC-LOAD 


ap-id 


AP-ID 


tx-level 


TX-LEVEL 


net-id 


NET-ID 


bch-rx-level 


BCH-RX-LEVEL 


rss-index-list 


RSS-INDEX-LIST 


rss-statistics-list 


RSS-STATISTICS-LIST } 



5.2.2.6 



Change Frequency 



The AP shall broadcast the RLC_CHANGE_FREQUENCY message, before changing the operating frequency. The AP 
should use the MAC broadcast sleep group frames for broadcasting the RLC_CHANGE_FREQUENCY message. 

The AP shall transmit the RLC_CHANGE_FREQUENCY message in RBCH more than once before the change of 
frequency. 
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MSC change_frequency 



MT ENV 



MT RCP 



AP RCP 



AP ENV 



Active Mode 



RRC_change_frequency_ind 



( RRC:-CHANGE-FREQUENCY-ARG) 



RRC_chang e_f requ encyjnd 



( RRC-CHANGE-FREQUENCY-ARG) 



Change Frequency 



RRC_change_frequency_req 



{ RRC-CHANGE-FREQUENCY-ARG| 
RLC CHANGE FREQUENCY 



( {first-mac-frame, 

last-mac-frame, 

frequency-index}) 



RLC CHANGE FREQUENCY 



( {first-mac-frame, 

last-mac-frame, 

frequency-index}) 



Active Mode 



Change Frequency 



Diagram 52: Change Frequency procedure 



Table 68: RLC-CHANGE-FREQUENCY 



RLC-CHANGE-FREQUENCY-ARG ::= SEQUENCE ■ 
ric-pdu-type RLC-SCH-PDU-TYPE 

first-mac-frame FIRST-MAC-FRAME 
last-mac-frame LAST-MAC-FRAME 

frequency-index FREQUENCY-INDEX } 
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5.2.3 Transmission Power Control 



5.2.3.1 



Uplink power control 



The MT shall operate with a transmission power > -15 dBm. The maximum output power is an arbitrary power level 
within the regulatory requirements. The transmission power range shall be composed of power steps equal to or smaller 
than 3 dB, and the transmitting MT shall ensure that the power levels shall provide monotonia transmission power. The 
MT shall define its' transmission power level at the ARP as: 

min (AP_Tx_Level - MT_received_power_level + AP_Rx_UL_Level + E(PC_Offset), AP_Tx_Level, maximum 
output power of MT) 

Where AP_Tx_Level denotes access point transmit power level and AP_Rx_UL_Level stands for the power level the 
access point is expecting to receive for all uplink signals. These values are transmitted as part of the BCH 
information [3]. MT_received_power _level is the estimated power level of the signal received by the MT. 

X(PC_Ojfset) is the sum of the received PC_Offset values from the AP. It is optional for AP to send PC_Offset values. 
The algorithm when to send the RLC_UPLINK_PC_CALIBRATION message is vendor specific issue. To send the 
PCjOffset value, AP shall use the RLC_UPLINK_PC_CALIBRATION message dedicated to a single MT. When no 
PC_Ojfset value has been received from the AP, the value X(PC_Ojfset) = shall be used. The maximum minimum 
values for Z(PC_Ojfset) shall be +15 and -20 dB, respectively. The RLC_UPLINK_PC_CALIB RATION message 
shown in table 69 may be transmitted from the AP to the MT at any time after association. When a handover to another 
AP is performed by the MT, a PC -reset is performed, i.e. 2jPC_0ffset) = 0. The AP may also force a PC-reset at any 
time. No reset is performed at sector handover. The MT shall apply the updated JjPC_Offset) value no later than 
2 MAC frames after the frame where the RLC_UPLINK_PC_CALIBRATION message was received. When the AP 
has transmitted an RLC_UPLINK_PC_CALIB RATION message to a MT, AP shall wait at least 10 MAC frames until 
the next calibration message may be transmitted to the MT. 



MSC uplink_pc_calibration 

MT ENV 



MT RLC 



AP RLC 



AP ENV 



Active mode 



( RRC-UPLINKPC-CALIBRATION-ARG) 
RLC UPLINK PC CALIBRATION 



RRC_uplink_pc_calibration_ind 



( RRC-UPLINK-PC-CALIBRATION-ARG) 



RRC_uplink_pc_calibration_req 



{ {pc- offset}) 



Active mode 



Diagram 53: Uplink power control calibration 
Table 69: RLC-UPLINK-PC-CALIBRATION 



RLC-UPLINK-PC-CALIBRATION-ARG ::= SEQUENCE { 
ric-pdu-type RLC-SCH-PDU-TYPE 
pc-offset PC-OFFSET } 
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5.2.3.2 Downlink Power Control 



Downlink power control is an implementation specific issue. In order to avoid interoperability problems the following 
restrictions apply to the default/normal downlink power control operation: 

The AP shall use the power levels and accuracy specified in [4] . 

The AP power can be decreased rapidly (3 dB/frame) without limitation on the dynamic range. 

The AP transmitter power shall not be changed more than 3 dB between two consecutive MAC frames. 

The AP shall not increase the transmitter power more than three steps (9 dB) during any 5 minute interval. 

The AP shall ensure that it is compliant with the maximum allowed transmitted power for the center frequency 
where it is operating. 

Spectrum regulatory requirements states that the interference to other radio systems than HlPERLAN/2 shall be reduced 
as far as possible, but at least with 3 dB in average compared to transmission at full power by all APs and all MTs. This 
requirement implies that the AP should posses some degree of DL power control functionality. 

5.2.3.3 Direct Link Power Control (OAP/OMT) 

The MT shall be able to operate with a transmission power > -15 dBm. The accuracies are given in TS 101 475 [4]. 

A fixed power control shall be supported by all MTs and the AP/CC in DM. This fixed power control requires that each 
DM capable device shall set its transmission power level 3 dB below the maximum allowed transmitted power for the 
centre frequency where it is operating (see TS 101 475 [4], clause 5.8.1.1). The usage of this fixed power control is only 
mandatory, if DiL power control using any other algorithm is not possible. Business or Home Environment Profiles (see 
TS 101 761-3 [13] and TS 101 761-5 [14]) may specify a more accurate DiL power control scheme. 

5.2.4 MT Alive 

This function is used for checking that an MT and an AP can communicate with each other. In turn, this shall be used 
for deciding on whether the AP and the MT are still associated to each other and on whether a MAC ID is free to use or 
occupied. 

If the AP sends RLC_MT_ALIVE_REQUEST message, the MT shall respond with the 
RLC_MT_ALIVE_REQUEST_ACK. 

The AP should set mt-alive-interval time for the MT in the RLC_MT_ALIVE_REQUEST message. The MT shall 
respond to this message by sending RLC_MT_ALIVE_REQUEST_ACK message. Within the set interval, the MT shall 
send the RLC_MT_ALIVE message periodically to remain associated. 

NOTE 1: The AP may also send the RLC_MT_ALIVE_REQUEST periodically, which should be the same period 
that the AP has set to the MT. 

NOTE 2: If the mt-alive-interval is set to zero, the MT is not expected to send the RLC_MT_ALIVE message 
periodically, but the AP is expected to take care of the MT Alive function. 

If the MT does not respond within the given period with the RLC_MT_ALIVE message, the AP should send the 
RLC_MT_ALIVE_REQUEST message to the MT. If the MT does not respond with 

RLC_MT_ALIVE_REQUEST_ACK when requested, the AP should remove the association of the particular MT 
(implicit disassociation procedure, no Disassociation message exchange). 

There is a possibility to increase the number of failed MT Alive procedures (retransmissions included) before 
Disassociation takes place. The number can be from one to four failures. 

NOTE 3: When the MT sends MT_ALIVE_REQUEST it becomes active. 
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MSC MT_Alive_AP_initiated 

MT ENV MT RLC 



AP RLC 



AP ENV 



Acti ve_mod e_o r_Sle ep_m ode 



RLC_MT_ALIVE_REQU ES| 



RRC_mt_alive_request_ind 



RRC-MT-ALIVE-REQUEST-ARCi) 



RRC_mt_al ive_request_rsp 



( {mt-alive-interval, 

no -of-mt- alive-procedures}) 



(RRC-MT-ALIVE-REQUEST-ACK-ARG ) 

RLC MT ALIVE REQUEST ACK 



({mac-id} ; 



RRC_mt_alive_request_req 



RRC-MT-ALIVE-REQUEST-ARG) 



T_mt_alive_request 



RRC_mt_alive_request_cnf 



(RRC-MT-ALIVE-REQUEST-ACK-ARG 



AcUve mode 



Diagram 54: MT alive procedure - AP initiated 



Table 70: RLC-MT-ALIVE-REQUEST 



RLC-MT-ALIVE-REQUEST-ARG ::= SEQUENCE { 
ric-pdu-type RLC-SCH-PDU-TYPE 

no-of-mt-procedures NO-OF-MT-ALIVE-PROCEDURES 
mt-alive-interval MT-ALIVE-INTERVAL OPTIONAL } 



Table 71 : RLC-MT-ALIVE-REQUEST-ACK 



RLC-MT-ALIVE-REOUEST-ACK-ARG :> 


= SEQUENCE! 


rIc-pdu-type 


RLC-SCH-PDU-TYPE 




mac-id 


MAC-ID} 
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MSC MT Alive MT initiated 



MT ENV 



MT RLC 



AP RLC 



AP ENV 



Active_Mode_or_Sleep_Mode 



RRC_mt_alive_req 



(RRC-MT-ALIVE-ARG ) 



T mt alive 



RRC mt alive cnf 



( RRC-MT-ALIVE-ACK-ARG) 



RLC MT ALIVE 



({mac-id} ) 



RLC MT ALIVE ACK 



RRC mt alive ind 



(RRC-MT-ALIVE-ARG ) 
RRC_mt_alive_rsp 



RFIC-MT-ALIVE-ACK-ARG) 



Active mode 



Diagram 55: MT alive procedure - lUIT initiated 
Table 72: RLC-MT-ALIVE 



RLC-MT-ALIVE-ARG ::= SEQUENCE { 
ric-pdu-type RLC-SCH-PDU-TYPE 
mac-id MAC-ID} 



Table 73: RLC-MT-ALIVE-ACK 



RLC-MT-ALIVE-ACK-ARG ::= SEQUENCE ■ 
rIc-pdu-type RLC-SCH-PDU-TYPE } 



5.2.5 MT Absence (OAP/OMT) 



This procedure is used by the MT to announce that it is temporary unavailable for the current AP, e.g. in order to 
perform measurements on neighbouring APs. During this time, no communication between MT and the current AP is 
possible. 

The MT should inform the AP that it would be absent with the RLC_MT_ABSENCE message and tell the absence 
time. The AP shall respond with the RLC_MT_ABSENCE_ACK message. The absence time is started from the frame 
the RLC_MT_ABSENCE_ACK is received (the next frame is number 1, etc.). During this time the MT and the AP 
cannot communicate.. After the absence period (n frames) the MT and AP shall immediately continue with normal 
operation. After this period the MT shall execute the MT Alive sequence, if the MT has no data is to be transmitted. In 
all cases the AP may send the RLC_MT_ALIVE_REQUEST message after the absent period to check if the MT is 
available. 

NOTE 1 : The AP should take care of its own processing delays, when counting the returning moment of the MT. 

NOTE 2: The MT should take care of its own processing delays, when counting the returning moment to the AP. 
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MSC MT Absence 

MT ENV 



MT RLC 



AP RLC 



AP ENV 



Active Mode with normal Communication 







RRC_absence_req 


RLC_MT_ABSENCE 










(RRC-MT-ABSENCE-ARG ) 


RRC_absence_request_ind 






({mt-absence-time, 
mac-id} ) 

RLC_MT_ABSENCE_ 


_ACIf 






T_mt_absence 




(RRC-MT-ABSENCE-ARG ) 

RRC_absence_rsp 






RRC-MT-ABSENCE-ACK-ARG) 




Absence_Frame_C 
( mt-absence-time 


X 

ounter ^^ 
) 

RRC_absence_cnf 
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Diagram 56: MT absence procedure 



Table 74: RLC-MT-ABSENCE 



RLC-MT-ABSENCE-ARG ::= SEQUENCE { 
ric-pdu-type RLC-SCH-PDU-TYPE 
mt-absence-time MT-ABSENCE-TIME 
mac-id MAC-ID } 



Table 75: RLC-MT-ABSENCE-ACK 



RLC-ABSENCE-ACK-ARG ::= SEQUENCE { 
ric-pdu-type RLC-SCH-PDU-TYPE } 
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5.2.6 Power Saving (OMT) 
5.2.6.1 General 

To allow reduced power consumption for mobile terminals the power save function can be used. 

A mobile can enter one out of sixteen different sleep groups to reduce its power consumption. The term sleep mode is 
used to refer to a mobile that has joined one of the sleep groups. 

A mobile terminal in sleep mode shall monitor the BCCH content periodically, as opposed to active mode where mobile 
terminal shall monitor the BCCH in every frame. The term wake-up frame refers to the frame where the mobile 
terminal in sleep mode monitors the BCCH. 

The AP/CC should maintain an internal sleep state for each MT being either active or sleep. The MT should maintain an 
internal sleep state being either active or sleep. 

In order to enter sleep mode the MT shall request the AP by sending a RLC_SLEEP message and receive a positive 
acknowledgement in RLC_SLEEP_ACK message. 

The sleep state shall be changed to sleep at the AP at the transmission of the RLC_SLEEP_ACK message. The sleep 
state should be changed to sleep at the MT at the reception of the RLC_SLEEP_ACK message indicating an acceptance 
to enter sleep mode. 

The AP should change the sleep state to active at arbitrary message reception from an MT with current sleep state 
active. The MT shall change its sleep state to active at decoding of the FCCH IE with a matching MAC ID that 
corresponds to the MT's MAC ID if current sleep state is sleep. The MT shall change its sleep state to active at arbitrary 
message transmission. 

NOTE 1: As is given by the rules above for sleep ^ active transitions, the MT will always be in active state if it 
receives an arbitrary unicasted message. 

NOTE 2: According to the rules above will broadcasted or multicasted messages, i.e. UBCH, UMCH and RBCH, 
not cause any change of sleep state for an MT. 

Sixteen sleep groups exists, where the sleep mode periodicity is given by: 

2" with (1 < n < 16) with the unit frames. 

The AP shall coordinate the sleep groups such that the periodicity for all sleep groups coincide with the periodicity for 
sleep group with n = 1. The latter will guarantee that for arbitrary sleep group m (m > 1), all sleep groups with shorter 
periodicity will at regular interval have their wake up frames equal to wake up frame for sleep group m. 

An MT in sleep mode shall monitor the BCCH at the wake-up frames that corresponds to the sleep group. Upon such a 
wake-up frame, if the BCCH DST [5] indication is active, the MT shall proceed to decode the FCCH. The FCCH may 
indicate a change of sleep state to active, or may indicate the presence of granted UBCH or UMCH in the frame. The 
DST indication also requires the MT to decode the following frame and apply the same decoding rules as for the current 
wake up frame. The BCCH may also contain an DL RBCH Indicator, that when set active requires the MT to decode 
the FCCH. The wakeup will in that case contain a granted RBCH. 

The AP shall internally select a MAC broadcast sleep group, denoted n^p, out of a subset from the sixteen sleep groups. 
An exemplatory wake-up frame for the MAC broadcast sleep group is denoted MAC broadcast frame. 

The periodicity of the MAC broadcast sleep group is given by: 
2"^^ with (5 < n < 16) with the unit frames. 

MAC broadcast frames can be used by the AP to transmit multicast and broadcast data since the wake-up frame for all 
MTs in sleep mode, with sleep group n <_n^^, will coincide with MAC broadcast frames. 



£75/ 



93 



ETSI TS 101 761-2 VI .3.1 (2002-01) 



The AP may transmit multicast and broadcast data in the following frames after a MAC broadcast frame by using the 
DST indication in the BCCH set active until the transmission is completed. The MTs will then revert to their 
active/sleep state they had prior to the MAC broadcast frame. This allows for a scalable broadcast and multicast 
bandwidth for sleeping MTs. 

For MTs with a sleep group n < n^p, the wake-up frames in between the MAC broadcast frames are denoted 
subBroadcast frames. 



MSC PowerSaving 




Diagram 57: Power saving procedures 
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Figure 7: Example of the lUIAC Broadcast frames and subBroadcast frames 
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NOTE 3: In the example the MT3 listens only the MAC broadcast frames (repeated once per N frames), the MT2 
has a sleep mode period of N/2 frames and the MTl has a sleep mode period of N/4 frames. Thus, the 
MT2 listens to MAC broadcast frames and always one subBroadcast frame between MAC broadcast 
frames. The MTl listens to three subBroadcast frames between MAC broadcast frames. The interval of 
subBroadcast frames is the result of allocating different, but synchronized sleep mode periods for MTs. 

5.2.6.2 MT sleep request procedure 

The MT shall not send RLC_SLEEP message (enter the sleep mode) during the association and handover procedures, 
see clauses 5.1.1 and 5.2.1. 

Apart from the exception above, the MT may at any time request to enter sleep mode, by sending the RLC_SLEEP 
message. The message shall contain a proposed sleep-group. The sleep-group shall be: 

1 < Sleep-group < 16. 
NOTE: The corresponding sleep mode periodicity is 2**l'='=P"g™"P with the unit frames. 

Based upon the internally selected MAC broadcast sleep group, n^^, the AP shall determine the sleep group according 
to the following formulas: 

If sleep-group <_n^p, then the sleep group for the MT shall be equal to the proposed sleep-group. 

If sleep-group > n^p, then the sleep group for the MT shall be equal to n^^. 

Since the MT may request for sleep mode at any frame the AP shall set an offset parameter to align the MT to coincide 
with the periodicity that the AP has for the selected sleep-group. 

The offset parameter shall be the number of frames after the current frame, in which the RLC_SLEEP_ACK is 
transmitted, that shall elapse until the first wake-up frame appears for the selected sleep-group. 

- <_Offset < (2'^eep-group _ j) ^j^jj jjje unit frames. 

EXAMPLE: The AP has determined the sleep-group for an MT to be 2, with a sleep mode periodicity of 
4 frames. 

If the RLC_SLEEP_ACK is transmitted in the wake -up frame for the sleep group, the offset 
parameter will be equal to 3. 

If the RLC_SLEEP_ACK is transmitted in the frame prior to the wake-up frame for the sleep 
group, the offset parameter will be equal to 0. 

If the AP sets the sleep-group to zero, the MT shall not enter sleep mode. 

The response to a RLC_SLEEP shall be sent in RLC_SLEEP_ACK. 
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MSC Sleep_Request 

MT_ENV{ 



MT RLC 



AP RLC 



AP ENV 



Active Mode 



RRC_sleep_req 



(RRC-SLEEP-ARG ) 



RLC SLEEP 



T_sleep_request 



X — ({care-of-broadcast-flag, 
sleep-group, 
mac-id} 



Sleepjnterval = proposed 

Sleep Interval 

(2,4, 8, 16, ... Frames) 



RRC_sleep_ind 



(RRC-SLEEP-ARG ) 

RRC_sleep_rsp 



RLC SLEEP ACK ( RRC-SLEEP-ACK-ARG) 



RRC_sleep_rsp 



r {care-of-broadcast-flag, 
sleep-group, 
offset}) 



( RRC-SLEEP-ACK-ARG) 

Sleeping_Frame_Counter 
({sleepjnterval}) 



Sleep_Mode 



Diagram 58: Sleep request procedure 



Table 76: RLC-SLEEP 



RLC-SLEEP-ARG ::= SEQUENCE { 



ric-pdu-type 

care-of-broadcast 

sleep-group 

mac-id 



RLC-SCH-PDU-TYPE, 

CARE-OF-BROADCAST 

SLEEP-GROUP 

MAC-ID } 



Table 77: RLC-SLEEP-ACK 



RLC-SLEEP-ACK-ARG ::= SEQUENCE 



rIc-pdu-type 

care-of-broadcast 

sleep-group 

offset 



RLC-SCH-PDU-TYPE 

CARE-OF-BROADCAST 

SLEEP-GROUP 

FRAME-NUM} 
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5.2.6.3 AP Procedure 

5.2.6.3.1 AP Procedure for unicast data 

At the occurrence of pending unicast data to an MT with sleep state equal sleep, the AP shall initiate an AP wake-up 
procedure of the MT prior to transmission of the unicast data. The AP wake-up procedure shall occur at arbitrary 
wake-up frame for the corresponding sleep-group for the MT. 

At the wake-up frame, the AP shall: 

1) set the DST indication active in the BCCH [5]; 

2) allocate one uplink RG for DCCH (DLCC ID = 0) with one granted SCH for the corresponding MT. 

In order to improve the response probability from a MT in sleep, the AP may repeat the AP wake-up procedure at the 
subsequent frame after the wake-up frame. More generally, since the MT wake-up procedure is repeated until the DST 
indication is inactive, the AP may repeat the AP wake-up procedure at arbitrary frame until the DST indication is 
inactive. 

At the reception of arbitrary data from an MT with sleep state sleep the AP should change the sleep state to active. 

5.2.6.3.2 AP Procedure for broadcast data 

At the occurrence of pending broadcast data (i.e. UMCH and/or UBCH), with exception for data transmitted in RBCH, 
the AP may defer transmission until the MAC broadcast frame. If used, the AP shall set the DST indication in the 
BCCH to indicate the possible presence of either UMCH or UBCH data in the frame. 

For broadcast data that spans over multiple MAC frames, or due to the use of repetition mode, the AP may use the 
bandwidth scalability option to send UMCH and/or UBCH data at subsequent frames after the MAC broadcast frame. 
The DST indication shall be set in all subsequent frames after the MAC broadcast frame until the UMCH and/or UMCH 
transmission is completed. 

NOTE: Due to the MT wake-up procedure, the AP does not necessarily have to transmit UBCH and/or UMCH 
data in a frame where the DST indication is active. 

If the AP does not use the MAC broadcast frame for the transmission of broadcast data (i.e. UMCH and/or UBCH), 
with exception for data transmitted in RBCH, the DST indication shall be inactive. 

At the occurrence of pending broadcast data transmitted in RBCH, the AP may defer transmission until a MAC 
broadcast frame, or arbitrary wake-up frame. 

The DL RBCH Indication in BCCH [5] shall be active for all frames where RBCH is transmitted. 
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5.2.6.4 MT Procedure 



For an MT in sleep mode, the MT shall initiate the MT wake-up procedure at the wake-up frames for the corresponding 
sleep group. At the wake-up frame the MT shall decode the BCCH for the occurrence of the DST or DL RBCH 
indication [5]. 

If the DST indication is active and/or DL RBCH Indicator is active, the MT shall: 

1) Decode the FCCH: 

At the occurrence of an IE with MAC ID that corresponds to the MAC ID of the MT, the sleep state shall be 

set to active. 

NOTE 1 : An MT that changes its sleep state from sleep to active shall proceed according to the normal procedure 
for decoding FCCH. 

- At the occurrence of UBCH and/or UMCH, the MT receives UBCH and/or UMCH in the frame. 

At the occurrence of RBCH, the MT receives the RBCH in the frame. 

2) Decode the BCCH in the following frame and restart the MT wake-up procedure: 

If the DST indication is inactive and DL RBCH Indication is inactive, and the MT sleep state is sleep, the 
MT should revert to its low power mode until the expiration of the next wake -up frame. 

At the occurrence of pending data transmission for an MT in sleep state sleep, the sleep state should be changed to 
active. 

NOTE 2: An MT with sleep state active will continue by transmitting a resource request, which will change the 
sleep state from sleep to active at the AP. Normal data transmission will follow. 

Since it is likely that the MT from time to time will have failure in the CRC check of the BCH, or due to an internal MT 
error initiate the MT wake-up procedure at an incorrect frame. To mitigate the effect of the latter erroneous conditions 
the following rules shall be supported: 

• If the CRC check of the BCH fails for a frame where MT wake-up procedure is started, the sleep state of the 
mobile shall be unchanged, and the MT shall re-start the wake-up procedure in the following frame. 

If the CRC check of the BCH for the following frame is successful, the MT wake-up procedure shall 
continue. 

If the CRC check of the BCH for the following frame fails, the MT sleep state should be set to active. 

• If the frame counter in the BCCH differs from the frame counter in MT, the MT should align its own counter 
value according to the frame counter of the BCCH. 

NOTE 3: The MT has to take into account in which frame after the wake-up frame the MT wake-up procedure is 
started. 

5.3 Services supporting DUCC (DLC User Connection Control) 

This control function is responsible for setting up, maintaining, re-negotiating and closing a DLC user connection at the 
DLC layer. Its main functions are: 

Allocating the DLCC-ID for a new specific connection. 

- Setting up the connection at DLC layer. 

The MT is not allowed to send any DUCC message before being associated to the AP. 
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5.3.1 Unicast DUG Setup 



Unicast radio connection can be requested both by the AP and by the MT using the RLC_SETUP message. In the 
message the selected DLCC IDs and corresponding characteristics shall be included. 

The RLC_SETUP message may be sent at multiple occasions since the maximal numbers of DUCs are limited in the 
message. The duc-ext-ind shall be set to no-duc-ext (0) for the last RLC_SETUP message and to duc-ext (l)for all 
preceding RLC_SETUP messages. 

NOTE 1 : The duc-ext-ind mechanism is especially relevant during the network handover procedure, when the 

number of DUCs that have to be re-established via the radio interface are more than what can be sent in 
one RLC_SETUP message. 

NOTE 2: DLCC IDs for mobile originating RLC_SETUP messages does not have to be set. The dlcc-id values 
proposed by an MT can be ignored by the AP. 

The RLC_SETUP message shall not be used to modify existing DUCs. 

If the receiver of the RLC_SETUP message being either the AP or the MT is not able to accept the proposal made by 
the sender, it shall send an RLC_CONNECT message containing the receiver's proposal. To accept the proposal made 
by the sender, the receiver shall repeat the proposal of the sender in the RLC_CONNECT message. In order to reject the 
RLC_SETUP the receiver shall send RLC_RELEASE message and continue with the Release procedure, as described 
in clause 5.3.2. 

If the sender accepts the receivers proposal sent in the RLC_CONNECT message, the sender shall respond with 
RLC_CONNECT_ACK message. Otherwise the sender shall send RLC_RELEASE message and continue with the 
Release procedure, as described in clause 5.3.2. 

5.3.1 .1 AP Initiated DUG Setup (OAP/OMT) 

The AP can send RLC_SETUP message in order to establish unicast radio connections. In the message the selected 
DLCC IDs and corresponding characteristics shall be included. The AP sender shall not transmit downlink traffic to the 
DUCs that are included in the RLC_SETUP message until RLC_CONNECT message is received. 

If the AP accepts the MT's proposal of the DUCs included in the RLC_CONNECT message, the AP shall respond with 
RLC_CONNECT_ACK message. 

At the reception of the RLC_CONNECT message, for the DUCs included in the RLC_CONNECT message, the AP 
shall: 

• Discard all data in its reception buffer and optionally discard all data in its transmission buffer (the decision is 
vendor specific). 

• Set TxBoW and RxBoW to 0. 

• If the sender and/or receiver are in flow control state, exit the flow control state. 

• Clear all other ARQ state information, i.e. acknowledgement bitmaps. 

• Set the DUC characteristics as included in the RLC_CONNECT message. 

If the AP does not accept the MT's proposal sent in the RLC_CONNECT message, the AP shall send the 
RLC_RELEASE message and continue with the Release procedure, as described in clause 5.3.2. 

If the MT is not able to accept the proposal made by the AP in the RLC_SETUP message, it shall send 
RLC_CONNECT message containing the MT's proposal. To accept the proposal made by the AP, the MT shall repeat 
the proposal of the AP in the RLC_CONNECT message. The MT sender shall not transmit uplink traffic to the DUCs 
that are included in the RLC_CONNECT message until RLC_CONNECT_ACK message is received. 
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At the transmission of the of the RLC_CONNECT message, for the DUCs included in the RLC_CONNECT message, 
the MT shall: 

• Discard all data in its reception buffer and optionally discard all data in its transmission buffer (the decision is 
vendor specific). 

• Set TxBoW and RxBoW to 0. 

• If the sender and/or receiver are in flow control state, exit the flow control state. 

• Clear all other ARQ state information, i.e. acknowledgement bitmaps and rtt awareness for resource request. 

• Set the DUC characteristics as included in the RLC_CONNECT message. 

In order to reject the RLC_SETUP the MT shall send RLC_RELEASE message and continue with the Release 
procedure, as described in clause 5.3.2. 

NOTE: DLCC IDs for mobile originating RLC_SETUP messages does not have to be set. The dlcc-id values 
proposed by an MT can be ignored by the AP. 

MSC Setup_Radio_Connection_mobile_terminated 



MT ENV 



MT_RLC 



AP RLC 



AP ENV 



Associated 



DUC_setup_ind 



(DUC-SETUP-ARG) 
DUC_connect_req 



(DUC-CONNECT-ARG ) 



T_connect_mt 



DUC_connect_cnf 



( D U C-CON N ECT-ACK-ARG) 



DUG_setup_req 



RLG_SETUP 

{cl-id, 

duc-ext-ind, 

cl-conn-attr-length, 

duc-descr-list}) 



-% 



(DUG-SETUP-ARG) 



RLC GONNEGT 



T setup_ap 



({cl-id, 

cl-conn-attr-iength, 
duc-descr-list} ) 



DUC connect ind 



(DUC-GONNECT-ARG) 

DUG_connect_rsp 



RLC_CONNEGT_ACK ( DUC-GONNECT-ACK-ARG) 



( {ci-id, 

ci-conn-attr-iength, 

dicc-descr-iist}) 



DUC^established 



Diagram 59: Mobile terminated connection Setup procedure 



Table 78: RLC-SETUP 



RLC-SETUP-ARG ::= 


SEQUENCE! 


ric-pdu-type 


RLC-LCH-PDU-TYPE 


cl-id 


CL-ID 


duc-ext-ind 


DUC-EXT-IND 


cl-conn-attr-length 


INTEGER(0..31) 


duc-descr-list 


DUC-DESCR-LIST} 
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Table 79: RLC-CONNECT 



RLC-CONNECT-ARG 


:= SEQUENCE { 


ric-pdu-type 


RLC-LCH-PDU-TYPE 


cl-id 


CL-ID 


cl-conn-attr-length 


INTEGER(0..31) 


duc-descr-list 


DUC-DESCR-LIST} 



Table 80: RLC-CONNECT-ACK 



RLC-CONNECT-ACK-ARG ::= SEQUENCE { 



ric-pdu-type RLC-LCH-PDU-TYPE 

cl-id CL-ID 

ci-conn-attr-iengtti iNTEGER(0..31 ) 

dicc-descr-iist DLCC-DESCR-LIST } 



5.3.1 .2 MT initiated DUG Setup 

The MT can send RLC_SETUP message in order to establish unicast radio connections. In the message the selected 
DLCC IDs and corresponding characteristics shall be included. The MT sender shall not transmit uplink traffic to the 
DUCs that are included in the RLC_SETUP message until RLC_CONNECT message is received. 

If the MT accepts the AP's proposal of the DUCs included in the RLC_CONNECT message, the MT shall respond with 
RLC_CONNECT_ACK message. 

At the reception of the RLC_CONNECT message, for the DUCs included in the RLC_CONNECT message, the MT 
shall: 

• Discard all data in its reception buffer and optionally discard all data in its transmission buffer (the decision is 
vendor specific). 

• Set TxBoW and RxBoW to 0. 

• If the sender and/or receiver are in flow control state, exit the flow control state. 

• Clear all other ARQ state information, i.e. acknowledgement bitmaps and rtt awareness for resource request. 

• Set the DUC characteristics as included in the RLC_CONNECT message. 

If the AP is able to accept the proposal made by the MT in the RLC_SETUP message completely, it shall send 
RLC_CONNECT message containing the MT's proposal. To accept the proposal made by the MT, the AP shall repeat 
the proposal of the MT in the RLC_CONNECT message. The AP sender shall not transmit downlink traffic to the 
DUCs that are included in the RLC_CONNECT message until RLC_CONNECT_ACK message is received. 

If the AP does not accept the proposal made by the MT completely, it shall send an RLC_CONNECT message with the 
AP's new proposal. 

If the MT does not accept the AP's proposal sent in the RLC_CONNECT message, the MT shall send the 
RLC_RELEASE message and continue with the Release procedure, as described in clause 5.3.2. 

If the AP is not able to accept the proposal made by the MT and can not send an alternative to the MT, the AP shall 
send an RLC_RELEASE message and continue with the Release procedure, as described in clause 5.3.2. 
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At the transmission of the of the RLC_CONNECT message, for the DUCs included in the RLC_CONNECT message, 
the AP shall: 

• Discard all data in its reception buffer and optionally discard all data in its transmission buffer (the decision is 
vendor specific). 

• Set TxBoW and RxBoW to 0. 

• If the sender and/or receiver are in flow control state, exit the flow control state. 

• Clear all other ARQ state information, i.e. acknowledgement bitmaps. 

• Set the DUC characteristics as included in the RLC_CONNECT message. 



MSC Setup_Radio_Connection_mobile_originated 

MT ENV I I MT_RLC 



Associated 



AP_RLC 



AP ENV 



DUC_setup_req 



(DUC-SETUP-ARG) 



T_setup_mt 



RLC_SETUP 



({cl-id, 
duc-ext-ind, 
cl-conn-attr-length, 
duc-descr-list{ 

{direction, 

dicc-id, 

cl-conn-attr, 

forward-descr 

bacl<ward-descr}}} ) 

duc-descr-list field 
is expanded to show 
an example of its inner 

structure 



]\ 



RLC CONNECT 



DUC connect Irtd 



(DUC-CONNECT-ARG) 



( {cl-id, 

cl-conn-attr-length, 

duc-descr-list}) 



DUC_connect_rsp 



(DUC-CONNECT-ACK-ARG ) 



RLC CONNECT ACK 



Tconnect_ack Jx ({d-id, 

cl-conn-attr-length, 
dicc-descr-list} ) 



TJink_capability_ack 
T_key_exchange_ap 
Tauthenticationack 

T dm_common_key_di^tr_ack 

T_info_ack 

T_nw_sig nail ing_h and o4er_ack 



DUC_setupJnd 



(DUC-SETUP-ARG) 



DUC_connect_req 



(DUC-CONNECT-ARG) 
T_connect_ap 



DUC connect cnf 



(DUC-CONNECT-ACK-ARG) 



DUC established 



Diagram 60: Mobile originated connection Setup procedure 
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If AP is not able to accept the proposal made by MT, it shall send RLC_CONNECT message containing AP's proposal. 
To accept the proposal made by the MT, the AP shall repeat the proposal of the MT in the RLC_CONNECT message. 
In order to reject the SETUP the AP shall send RLC_RELEASE message and continue with the Release procedure, as 
described in clause 5.3.2. 

If the MT accepts AP's proposal sent in the RLC_CONNECT message, the MT shall respond with 
RLC_CONNECT_ACK message. Otherwise the MT shall send RLC_RELEASE message and continue with the 
Release procedure, as described in clause 5.3.2. 

5.3.2 Unicast DUG release 



5.3.2.1 



AP Initiated DUG Release 



In case of an AP Initiated Connection Release the AP shall send an RLC_RELEASE message commanding the MT to 
release one or multiple unicast DUCs. In this message the AP shall indicate to the MT the selected DLCC IDs of the 
respective DUCs. 



MSC Release_Radio_Connection_mobile_originatecl 



MT ENV 



MT RLC 



AP RLC 



AP ENV 



DUG established 



DUC_release_req 



(DUC-RELEASE-ARG ) 



T release mt 



DUG release cnf 



( DUG-RELEASE-ACK-ARG) 



RLC RELEASE 



({release-cause, 
dice- id-list } 



RLC RELEASE AGK 



( {dicc-id-list}) 



DUC release ind 



(DUC-RELEASE-ARG ) 

DUG_release_rsp 



DUG-RELEASE-ACK-ARG) 



DUG released 



Diagram 61 : Mobile terminated connection release procedure 



Table 81 : RLC-RELEASE 



RLC-RELEASE-ARG ::= SEQUENCE { 



ric-pdu-type RLC-LCH-PDU-TYPE 



release-cause RELEASE-CAUSE 
dicc-id-list DLCC-ID-LIST} 



Table 82: RLC-RELEASE-ACK 



RLC-RELEASE-ACK-ARG ::= SEQUENCE ■ 



rIc-pdu-type RLC-LCH-PDU-TYPE 

dicc-id-list DLCC-ID-LIST} 



The MT shall respond with RLC_RELEASE_ACK indicating that the relevant DLCC IDs are released. 
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5.3.2.2 



MT Initiated DUG release 



In case of an MT Initiated Connection Release the MT shall send an RLC_RELEASE message requesting the AP to 
release one or multiple unicast DUCs. In this message the MT shall indicate to the AP the selected DLCC IDs of the 
respective DUCs. 



MSC Release_Radio_Connection_mobile_terminatecl 

MT ENV MT RLC 



AP RLC 



AP ENV 



DUG established 



DUG release ind 



( DUC-RELEASE-ARG) 
DUG_release_rsp 



(DUG-RELEASE-ACK-ARG ) 



DUG_release_req 



RLC RELEASE 



( DUC-RELEASE-ARG) 



( {release-cause, 
dicc-id-list}) 



RLC RELEASE ACK 



({dicc-id-list} 



T_release_ap 



DUG release cnf 



(DUG-RELEASE-ACK-ARG ) 



DUG released 



Diagram 62: Mobile originated connection release procedure 

The AP shall respond with RLC_RELEASE_ACK indicating that the relevant DLCC IDs are released. 

5.3.3 Unicast DUG modify (OAP/OMT) 

Existing unicast radio connection can be modified by both the AP and by the MT using the RLC_MODIFY_REQ 
message. In the message the selected DLCC IDs of the respective unicast DUCs and their new characteristics shall be 
included. 

The RLC_SETUP message may be sent at multiple occasions changing the characteristics for the same DUC. 

The RLC_MODIFY_REQ message shall be used to modify existing DUCs. 

If the receiver of the RLC_MODIFY_REQ message being either the AP or the MT is not able to accept the proposal 
made by the sender, it shall send an RLC_MODIFY message containing the receiver's proposal. To accept the proposal 
made by the sender, the receiver shall repeat the proposal of the sender in the RLC_MODIFY message. 

If the sender accepts the receivers proposal sent in the RLC_MODIFY message, the sender shall respond with 
RLC_MODIFY_ACK message. Otherwise the sender shall send RLC_RELEASE message and continue with the 
Release procedure, as described in clause 5.3.2. 
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5.3.3.1 AP Initiated DUG modify 

The AP can send RLC_MODIFY_REQ message in order to modify existing unicast radio connections. In the message 
the selected DLCC IDs of the respective unicast DUCs and their new characteristics shall be included. The AP sender 
shall either stop transmitting downlink traffic to the DUCs that are included in the RLC_MODIFY_REQ message, or 
transmit dummy PDUs, until RLC_MODIFY message is received. 

If the AP accepts the MT's proposal of the DUCs included in the RLC_MODIFY message, the AP shall respond with 
RLC_MODIFY_ACK message: 

At the reception of the RLC_MODIFY message, for the DUCs included in the RLC_MODIFY message, the AP shall: 

• Discard all data in its reception buffer and optionally discard all data in its transmission buffer (the decision is 
vendor specific). 

• Set TxBoW and RxBoW to 0. 

• If the sender and/or receiver are in flow control state, exit the flow control state. 

• Clear all other ARQ state information, i.e. acknowledgement bitmaps. 

• Set the DUC characteristics as included in the RLC_MODIFY message. 

If the AP does not accept the MT's proposal sent in the RLC_MODIFY message, the AP shall send the 
RLC_RELEASE message and continue with the Release procedure, as described in clause 5.3.2. 

If the MT is not able to accept the proposal made by the AP in the RLC_MODIFY_REQ message, it shall send 
RLC_MODIFY message containing the MT's proposal. To accept the proposal made by the AP, the MT shall repeat the 
proposal of the AP in the RLC_MODIFY message. The MT sender shall either stop transmitting uplink traffic to the 
DUCs that are included in the RLC_CONNECT message, or transmit dummy PDUs, until RLC_MODIFY_ACK 
message is received. 

At the transmission of the of the RLC_MODIFY message, for the DUCs included in the RLC_MODIFY message, the 
MT shall: 

• Discard all data in its reception buffer and optionally discard all data in its transmission buffer (the decision is 
vendor specific). 

• Set TxBoW and RxBoW to 0. 

• If the sender and/or receiver are in flow control state, exit the flow control state. 

• Clear all other ARQ state information, i.e. acknowledgement bitmaps and rtt awareness for resource request. 

• Set the DUC characteristics as included in the RLC_MODIFY message. 
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MSC Modify_Radio_Connection_mobile_term inated 



MT ENV 



MT RLC 



AP RLC 



AP ENV 



DUG established 



DUC_modifyreq_req 



RLC MODIFY REQ 



DUC_modifyreq_ind 



(DUC-MODIFY-REQ-ARG 



( DUC-MODIFY-REQ-ARG 
DUC_modify_req 



( {duc-ext-ind, 

cl-conn-attr-length, 

duc-descr-list}) 



-^ 



T_modify_req_ap 



RLC MODIFY 



(DUC-MODIFY-ARG 



({cl-conn-attr-length, 
duc-descr-list} 



DUC_modify_ind 



T_modify_mt 



RLC MODIFY ACK 



(DUC-MODIFY-ARG ) 

DUC_modify_rsp 

■^ 

( DUC-MODIFY-ACK-ARG ) 



DUC_modify_cnf 



( {cl-conn-attr-length, 
dicc-descr-list}) 



' DUC-MODIFY-ACK-ARG ' 



DUC established 



Diagram 63: Mobile terminated connection modify procedure 



Table 83: RLC-MODIFY-REQ 



RLC-MODIFY-REQ-ARG ::= SEQUENCE { 



ric-pdu-type RLC-LCH-PDU-TYPE 

duc-ext-ind DUC-EXT-IND 

cl-conn-attr-length INTEGER(0..31 ) 

duc-descr-list DUC-DESCR-LIST } 



Table 84: RLC-MODIFY 



RLC-MODIFY-ARG ::= SEQUENCE { 



rIc-pdu-type RLC-LCH-PDU-TYPE 

cl-conn-attr-length INTEGER(0..31 ) 
duc-descr-list DUC-DESCR-LIST } 



Table 85: RLC-MODIFY-ACK 



RLC-MQDIFY-ACK-ARG ::= SEQUENCE { 



rIc-pdu-type RLC-LCH-PDU-TYPE 

cl-conn-attr-length INTEGER(0..31 ) 
dicc-descr-list DLCC-DESCR-LIST } 
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5.3.3.2 MT Initiated DUG modify 



The MT can send RLC_MODIFY_REQ message in order to modify existing unicast radio connections. In the message 
the selected DLCC IDs of the respective unicast DUCs and their new characteristics shall be included. The MT sender 
shall either stop transmitting downlink traffic to the DUCs that are included in the RLC_MODlFY_REQ message, or 
transmit dummy PDUs, until RLC_MODIFY message is received. 

If the MT accepts the MT's proposal of the DUCs included in the RLC_MODIFY message, the MT shall respond with 
RLC_MODIFY_ACK message. 

At the reception of the RLC_MODIFY message, for the DUCs included in the RLC_MODIFY message, the MT shall: 

• discard all data in its reception buffer and optionally discard all data in its transmission buffer (the decision is 
vendor specific); 

• set TxBoW and RxBoW to 0; 

• if the sender and/or receiver are in flow control state, exit the flow control state; 

• clear all other ARQ state information, i.e. acknowledgement bitmaps and rtt awareness for resource request; 

• set the DUC characteristics as included in the RLC_MODIFY message. 

If the MT does not accept the MT's proposal sent in the RLC_MODIFY message, the MT shall send the 
RLC_RELEASE message and continue with the Release procedure, as described in clause 5.3.2. 

If the AP is not able to accept the proposal made by the MT in the RLC_MODIFY_REQ message, it shall send 
RLC_MODIFY message containing the AP's proposal. To accept the proposal made by the MT, the AP shall repeat the 
proposal of the MT in the RLC_MODIFY message. The AP sender shall either stop transmitting uplink traffic to the 
DUCs that are included in the RLC_CONNECT message, or transmit dummy PDUs, until RLC_MODIFY_ACK 
message is received. 

At the transmission of the of the RLC_MODIFY message, for the DUCs included in the RLC_MODIFY message, the 
AP shall: 

discard all data in its reception buffer and optionally discard all data in its transmission buffer (the decision is 
vendor specific); 

- set TxBoW and RxBoW to 0; 

if the sender and/or receiver are in flow control state, exit the flow control state; 

clear all other ARQ state information, i.e. acknowledgement bitmaps. 

Set the DUC characteristics as included in the RLC_MODIFY message. 
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MSC Modify_Radio_Connection_mobile_originated 



MT ENV 



MT_RLC 



AP_RLC 



AP ENV 



DUC_established 





D U C_modifyreq_req 


RLG_MODIFY_REQ 










(DUC-MODIFY-REQ-ARG ) 


DUC_modifyreqJnd 






({duc-ext-ind, 
cl-conn-attr-length, 
duc-descr-list} ) 

RLC_MODIFY 






T _m od i fy_re q_ mt 

> 
DUC_modify_ 


nd 


(DUC-MODIFY-REQ-ARG ) 

DUG_modlfy_req 






(DUC-MODIFY-ARG) 






( {cl-conn-attr-length, 
duc-descr-llst}) 

RLC_MODIFY_ACK 


T_modlfy_ap 
DUC_modify_cnf 






(DUC-MODIFY-ARG) 
DUC_modify_rsp 






(DUC-MODIFY-ACK-ARG ) 






({cl-conn-attr-length, 
dicc-descr-list} ) 










(DUC-MODIFY-ACK-ARG ) 





DUC_established 



Diagram 64: Mobile originated connection modify procedure 

The DUCs shall be reset, see clause 5.3.4. 

5.3.4 Unicast DUG Reset 

With the reset procedure the ARQ instances and related timers of one or more unicast DUCs shall be reset to their initial 
state. The DUC characteristics as agreed upon Setup or latest modification shall be maintained. The reset procedure 
shall be initiated by sending the RLC_RESET message including the DLCC lD(s) of the DUCs. The receiving entity 
(either MT or AP) shall acknowledge the Reset by responding with RLC_RESET_ACK indicating the corresponding 
DLCC ID(s). 

The ARQ sequence number of the established DUCs shall be reset to zero both in the MT and the AP. At the receiving 
entity (either MT or AP) RxBoW shall be reset to zero at the reception of the RLC_RESET message. At the sending 
entity (either MT or AP) TxBoW shall be reset to zero at the reception of the RLC_RESET_ACK message. 

A sender shall not send a duplicate RLC_RESET until RLC_RESET_ACK for this particular DUC is received or until 
the retransmit timer {T_reset_ap or T_reset_mt) expires. 

NOTE: The reset does only affect either uplink or downlink direction. 
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5.3.4.1 



AP Initiated DUG Reset 



The AP sender shall either stop transmitting downlink traffic related to the DUCs that are included in the RLC_RESET 
message after sending the RLC_RESET (including the current frame), or transmit dummy PDUs. The AP should not 
start transmitting downlink traffic related to the DUCs that are included in the RLC_RESET message before 
RLC_RESET_ACK is received. The AP shall reset the ARQ instance immediately after receiving RLC_RESET_ACK. 
The MT shall reset the ARQ instance immediately after receiving RLC_RESET. 

At the reception of RLC_RESET, for the DUCs that are included in the RLC_RESET message, the MT shall: 

• discard all data in its reception buffer; 

• set RxBoW to 0; 

• if the receiver is in flow control state, exit the flow control state; 

• clear all other ARQ state information, i.e. acknowledgement bitmap; 

• retain all DUC characteristics as agreed upon Setup or latest modification. 

At the reception of RLC_RESET_ACK, for the DUCs that are included in the RLC_RESET message, the AP shall: 

• optionally discard all data in its transmission buffer (the decision is vendor specific); 

• set TxBoW to 0; 

• if the sender is in flow control state, exit the flow control state; 

• clear all other ARQ state information, i.e. rtt awareness for resource requests; 

• retain all DUC characteristics as agreed upon Setup or latest modification. 

The AP shall not retransmit a duplicate RLC_RESET message, until either the retransmit timer expires or until the 
RLC RESET ACK is received. 



MSC Reset_mobile_terminated 

MT ENV MT RLC 



DUC reset ind 



( DUC-RESET-ARG) 
DUC_reset_rsp 



AP RLC 



AP ENV 



Associated 



;duc-reset-ack-arg ) 



RLC reset 


DUC_reset_req 


( DUC-RESET-ARG) 


RLC RESET ACK 


( {dicc-id-list}) 








T_reset_ap 


({dicc-id-list} ) 




DUC_ 


reset cnf 


(DUC-RESET-ACK-ARG ) 



DUC established 



Diagram 65: Mobile terminated reset procedure 
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Table 86: RLC-RESET 



RLC-RESET-ARG ::= SEQUENCE { 



ric-pdu-type RLC-LCH-PDU-TYPE 

dicc-id-list DLCC-ID-LIST} 



Table 87: RLC-RESET-ACK 



RLC-RESET-ACK-ARG ::= SEQUENCE { 



rIc-pdu-type RLC-LCH-PDU-TYPE 

dicc-id-list DLCC-ID-LIST} 



5.3.4.2 MI Initiated DUG reset 

The MT sender shall either stop transmitting uplink traffic related to the DUCs that are included in the RLC_RESET 
message after sending the RLC_RESET, or transmit dummy PDUs. 

The MT should not start transmitting uplink traffic related to the DUCs that are included in the RLC_RESET message 
before RLC_RESET_ACK is received. If the AP allocates uplink capacity for this particular DUC, the MT shall send 
either the dummy LCH PDU or leave the LCH unused if possible. 

The MT shall reset the ARQ instance immediately after receiving RLC_RESET_ACK. The AP shall reset the ARQ 
instance immediately after receiving RLC_RESET. 

At the reception of RLC_RESET, for the DUCs that are included in the RLC_RESET message, the AP shall: 

discard all data in its reception buffer; 

- set RxBoW to 0; 

if the receiver is in flow control state, exit the flow control state; 
clear all other ARQ state information, i.e. acknowledgement bitmap; 
retain all DUC characteristics as agreed upon Setup or latest modification. 
At the reception of RLC_RESET_ACK, for the DUCs that are included in the RLC_RESET message, the MT shall: 
optionally discard all data in its transmission buffer (the decision is vendor specific); 

- set TxBoW to 0; 

if the sender is in flow control state, exit the flow control state; 

clear all other ARQ state information, i.e. rtt awareness for resource requests; 

retain all DUC characteristics as agreed upon Setup or latest modification. 

The MT should not transmit a duplicate RLC_RESET message until either the retransmit timer expires or until the 
RLC RESET ACK is received. 
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MSC Reset_mobile_originated 

MT ENV MT RLC 



AP RLC 



AP ENV 



Associated 



DU C_reset_req 



(DUC-RESET-ARG 



T reset mt 



DUG reset cnf 



( DUC-RESET-ACK-ARG) 



RLC RESET 



({dicc-id-list} ) 



DUC reset ind 



(DUC-RESET-ARG 



DUC_reset_rsp 



RLC_RESET_ACK ( DUC-RESET-ACK-ARG) 

( {dicc-id-list}) 



DUC established 



Diagram 66: Mobile originated reset procedure 

5.3.5 Multicast DUC 

Multicast DUCs are implicitly set up by Group Join during the association procedure, as defined in clause 5.1.4. The 
MAC IDs and DLCC IDs reserved for multicast connections are defined in TS 101 761-1 [5]. 

5.3.6 Broadcast DUC 

Broadcast DUCs are implicitly set up by Broadcast Join during the association procedure, as defined in clause 5.1.5. 
The MAC IDs and DLCC IDs reserved for broadcast connections are defined in TS 101 761-1 [5]. 

5.3.7 Unicast Direct Linl< DUC Setup (OAP/OMT) 

The direct link (DiL), which is used in Direct mode (DM), allows direct connections between two or more MTs. The 
corresponding control functions are quite similar to those of the centralized mode (AP/CC and MT). But in this case 
there are one AP/CC and two MTs involved for a DiL unicast connection, as shown as in figure 8. 



CTRL 



CTRL 




Figure 8: Direct Linic connection between an AP/CC and two lUITs 
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The following basic characteristics are valid for the DiL: 

• the access point or central controller shall still control DUC establishment and modification; 

• a calibration mechanism may be used in the control plane, so that: 

any MT can know which other MTs it has radio contact with; 

the AP/CC can know the radio map of the network (which MT is in radio contact with which other MT); 

• if no means are available to check the connectivity to the peer DM device before DiL DUC Setup, the DiL DUC 
Setup shall be performed anyway. In this case the receiving MT shall monitor whether it is able to receive LCHs 
and/or SCHs of the related DiL DUC. This can be done by monitoring the RG for this DiL DUC. If for a number 
of consecutive RGs for this DiL DUC no LCH and/or SCH has been received successfully the receiving MT 
shall release this DiL DUC by performing the MT initiated DiL DUC release (see clause 5.3.8.2) procedure. The 
release-cause parameter of the RLC_DM_RELEASE message is set to low-qos. The number of consecutive RGs 
is out of the scope of the present document; 

• after receiving the RLC_DM_RELEASE message with release-cause equal to low-qos, the transmitting device 
may initiate a DiL DUC relay Setup (see clause 5.3.7.3), in order to establish a DiL DUC to the peer device via 
the AP/CC. 

The DUC procedures may request several connections, but all these connections shall belong to the same convergence 
layer. 

It may be possible for the higher layers to establish a connection between two MTs (MTl and MT2) even if there is no 
connectivity. In that case, the AP/CC shall act as a Relay by establishing two DiL connections between MTl and 
AP/CC and between AP/CC and MT2. 

The DUC descriptor field contains one direction descriptor for unidirectional or symmetric duplex connections and two 
direction descriptors for asymmetric duplex connections. These direction descriptors are called forward and backward 
descriptor. For unidirectional connection, due-direction field in DUC descriptor shall be set to simplex forward for the 
sender and simplex backward for the receiver. If it is set to simplex forward, then only the forward descriptor shall be 
present, and if it is set to simplex backward, then only the backward descriptor shall be present. For symmetric duplex 
connections the due-direction field in DUC descriptor shall be set to symmetric duplex, then the forward and backward 
descriptor would be identical, therefore only the forward descriptor shall be provided. For asymmetric duplex 
connections the forward descriptor is related to the sender and the backward descriptor is related to the receiver. The 
AP/CC is responsible for inverting the contents of the two descriptors for the two MTs involved in the DiL connection. 

All DiL DUC connection control messages shall be transmitted over uplink and downlink DCCH. The MAC ID 
contained in the messages are use to describe the peer MT. 

5.3.7.1 AP/CC initiated DM DUC Setup (OMT) 

If the Direct Mode is supported, the Relay Setup shall be implemented for the AP/CC. 

In case of an AP/CC initiated DiL connection set-up, the RLC shall send a RLC_DM_SETUP message, requesting the 
MT to establish one or multiple unicast DUCs. In this message the AP/CC shall indicate to the MT the selected DLCC 
IDs and their connection characteristics (i.e. direction, ARQ parameters, etc.). Referring to the following MSC, the 
peer-mac-id in the DiL DUC Setup messages from/to MTl shall be set to the MAC ID of the MT2 and the peer-mac-id 
in the DiL DUC Setup messages from/to MT2 shall be set to the MAC ID of the MTl. 

When the AP/CC requires to establish additional DUCs in a subsequent Setup procedure, the AP/CC should indicate 
this by setting the duc-ext-ind flag. The AP/CC shall use the forward direction for the MT that is the sender and the 
backward direction for the receiver MT. 

The MT shall respond with RLC_DM_CONNECT message. The connection characteristics shall not be modified by the 
MT. In order to reject the DiL Setup the MT shall send RLC_DM_RELEASE message and continue with the DiL 
Release procedure. The AP/CC shall send the RLC_DM_CONNECT_ACK message before continuing with the other 
MT. 
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The AP/CC shall run the same procedure for the second MT to negotiate the connection. If the second MT can not 
support the characteristics, it shall initiate the DiL Release procedure. 

The AP/CC can also act as one of the MTs, in this case the messages between this MT and the AP/CC are exchanged 
internally in the AP/CC. 



MSC Direct_Link_Setup_Radio_Connection_AP_initiated 

MT1 ENV MT1 RLC MT2 ENV MT2 RLC AP RLC 



AP ENV 



Associated 



(DUC-DM-CONNECT-ARG ) rlq DM CONtJECT 



T_dn_connect_cmpt_mt -yz 
T dm connect mt 



DUG dm connect cnf 



DUC_dm_setup_ind 



DUC-DM-SETUP-ARG) 
DUC_dm_connect_req 



DUC-DM-GONNECT-ACK-ARG) 



({peer-mac- id, 
cl-id, 

cl-conn-attr-len^tti, 
duc-descr-list} 



RLG DIVI SETUP 



cl-co 

I 

cl 



{peer-mac-id, 
cl-id, 
duc-ext-ind, 
nn-attr-length, 
duc-descr-list, 
common-attr}) 



.C DM GONNEGT AGK 



{peer-mac-id 
cl-id: 
cl-co nn-attr-length 
dicc-descr-list}) 



DUC_dm_setup_ind ( 



( DUG-DM-SETUP-ARG) 
DUC_dm_connect_req 



(DUC-[)M-GONNECT-ARG 
T_dm_con n ect_c mpt_m t X 



T (Jm connect mt 



D U C_d n" _CQ n ne ct_cn f 
( DUC-DM-GOKNEGT-ACK-ARG) 



DJC dm connect ind 



(DUC-DM-CONNECT-ARG 
[:iUC_dm_connect_rsp 



i DUf)-DM-CONNECT-ACK-,\RG) 



{peer-mac-id, 

cl-id, 

duc-ext-ind, 

cl-co nn-attr-length, 

duc-descr-list, 

cl-co mmon-dataj) 

)rLC dm CONNECT 



({peer-mac-id, 
cl-id, 

cl-conn-attr-length, 
duc-desCT-list} 



(peer-mac-id, 

cl-id, 

cl-conn-attr-length, 

dicc-descr-list}) 



DUC_dm_setup_req 



DUC-DM-SETUP-AR(p) 
T_dm_setup_ap 



DUC_dm_setup_req 



^RLC_DM_SETUp [^UC-DM-SETUP-ARG) 
T_dm_setup_ap 



DUG dm connect ind 



)(DUG-DM-GONNEGT 
DUC_dm_connect_rsp 



( DUG-DM-CONNEGT-AGK-ARq) 
RliC DM CONNECT /s.CK 



ARG ) 



Direct_Mode_Setup_Radio_Connection_completion 



DUG established 



Diagram 67: Direct Linit Setup procedure - AP/CC initiated 
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The message RLC_DM_CONNECT_COMPLETE shall be used to synchronize the two MTs after the connection 
phase. These messages may be sent in parallel to both MTs. 

If the MT does not receive the RLC_DM_CONNECT_COMPLETE message before the timer runs out, it shall not 
establish the connections and shall initiated the DiL Release procedure. After receiving this message, the MT shall 
respond with RLC_DM_CONNECT_COMPLETE_ACK message. 

In case of the connections use ARQ, the ARQ sequence number of the established DUCs shall be reset to zero in both 
MTs. TxBoW and RxBoW of the corresponding DUCs shall be reset to zero in both MTs. 



MSC Direct_Link_Setup_Radio_Connection_completion 



MT1 ENV 



MT1 RLC 



MT2 ENV 



MT2 RLC 



AP1 RLC 



AP2 RLC 



AP ENV 



T_dm_connect_cmbt_mt 

X — 

DUC_dm_conn_c()mplete_hd 

NECT-COMPLETE 
a)mplete_rsp 



( DUC-DM-CON 
DUC dm conn 



pUC-DM-CONNEC]r-COMPLETE-ACKARG ) 

RLC DM CONNECT COMPLETE 



RLC_:iM_CONNECT_COMPLETE ( DIJC-DM-CONNECT-COMPLETE-ARGi 



AR(3) 



({peer-mac-id, 
mac-id} ) 



T_dm_cor 
DUC_dm_cor 
{ DUp-DM-CONNECT- 
DUC_dm_cor 
(DUC-DM-CONNECT-COMF^LETE-ACK-ARG 



Dnn 



( {peer-mac-ic 
dicc-descr-li; 



isti) 



ACK 



iect_cmpt_mt 

X — 

i_complete_ind 



CpMPLETE-ARG) 
complete_rsp 



(DUC-DI\|l 
( DU 



FiLC DM CONNECT COMPLETE 



({peer-m: 
mac-id} 



(DUC-DM 



DUC_dm_ccinn_complete_req 



T_dm_connect_cmpt_ap 



DUC_dm_conn_complete_cnf 



ACK-ARG 
nn_complete_req 



■CONNECT-COMPLETE 

DUC_dm_cci 
■DM-CON NECT-pOMPLETE-ARG) 
RLC DM CONNECT COMPLETE 



{peer-mac-id, 
dlcc-descr-listj) 



ac-id. 



T_d m_c;o n nee t_cmpt_ap 



ACK 



DUC_dm_conri_complete_cnf 

• 

CONNECT -COM = LETE-ACK-ARG 



Diagram 68: Completion of direct linlt Setup procedure 



Table 88: RLC-DM-SETUP 



RLC-DM-SETUP-ARG 


::= SEQUENCE { 


ric-pdu-type 


RLC-LCH-PDU-TYPE 


peer-mac-id 


MAC-ID 


cl-id 


CL-ID 


duc-ext-ind 


DUC-EXT-IND 


cl-conn-attr-length 


INTEGER(0..31) 


duc-descr-list 


DUC-DESCR-LIST 


cl-common-attr 


CL-COMMON-ATTR } 
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Table 89: RLC-DM-CONNECT 



RLC-DM-CONNECT-ARG ::= SEQUENCE { 


ric-pdu-type 


RLC-LCH-PDU-TYPE 


peer-mac-id 


MAC-ID 


cl-id 


CL-ID 


cl-conn-attr-length 


INTEGER(0..31) 


duc-descr-list 


DUC-DESCR-LIST} 



Table 90: RLC-DM-CONNECT-ACK 



RLC-DM-CONNECT-ACK-ARG ;:= SEQUENCE { 


ric-pdu-type 


RLC-LCH-PDU-TYPE 


peer-mac-id 


MAC-ID 


ci-id 


CL-ID 


ci-conn-attr-iengtti 


iNTEGER(0..31) 


dicc-descr-iist 


DLCC-DESCR-LIST } 



Table 91 : RLC-DM-CONNECT-COMPLETE 



RLC-DM-CQNNECT-CQMPLETE-ARG ::= SEQUENCE { 



ric-pdu-type RLC-LCH-PDU-TYPE 

peer-mac-id MAC-ID 

dicc-id-list DLCC-iD-LIST} 



Table 92: RLC-DM-CONNECT-COMPLETE-ACK 



RLC-DM-CQNNECT-CQMPLETE-ACK-ARG ::= SEQUENCE { 



ric-pdu-type RLC-SCH-PDU-TYPE 

peer-mac-id MAC-ID 

mac-id MAC-ID } 



NOTE: The AP/CC may be one of the MTs, i.e. MTl or MT2. In this case, the messages shall be sent and 
received internally in the AP/CC. 



£75/ 



115 ETSI TS 101 761-2 VI .3.1 (2002-01) 

5.3.7.2 MT initiated DM DUG Setup (OMT) 

If the Direct Mode is supported, the Relay Modify shall be implemented for the AP/CC. 

A MT can also initiate one or several direct link connections by sending the RLC_DM_SETUP message. The MT shall 
make a proposal for the characteristics of the DLC user connections. In that case the DLCC IDs shall be set to zero. 
When the AP/CC receives this RLC_DM_SETUP message from MT, the AP/CC shall respond with 
RLC_DM_CONNECT with DLCC IDs selected by the AP/CC. The AP/CC may modify the connection characteristics. 
If the new characteristics are not acceptable for the initiating MT, it should reject the Setup by initiating a DiL Release 
procedure. 

If the MT has accepted the characteristics in the RLC_DM_CONNECT, the AP/CC shall connect the other MT with the 
same procedure as describe in the AP/CC initiated RLC_DM_ SETUP. 

NOTE: Messages RLC_DM_SETUP, RLC_DM_CONNECT and RLC_DM_CONNECT_ACK are used either in 
uplink or in downlink. 

Once parameters negotiated with the two MTs, the AP/CC shall send the RLC_DM_CONNECT_COMPLETE message 
to both MTs to indicate which of the connections shall be established. Then after receiving these messages, both MTs 
shall respond with RLC_DM_CONNECT_COMPLETE_ACK message. 

The ARQ sequence number of the established DUCs shall be reset to zero in both MTs. TxBoW and RxBoW of the 
corresponding DUCs shall be reset to zero in both MTs. 

Referring to the following MSC, the peer MAC ID in the DiL Due Setup messages from/to MTl shall be set to the 
MAC ID of the MT2 and the peer-mac -id in the DiL Due Setup messages from/to MT2 shall be set to the MAC ID of 
the MTL If the peer-mac-id is not known to RLC of the initiating MT, then it shall be set to its own value. In that case 
the peer MT is identified in convergence layer container and the AP/CC shall do the mapping. 

The AP/CC can also act as one of the MTs, in this case the messages between this MT and the AP/CC are exchanged 
internally in the AP/CC. 
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MSC Direct_Link_Setup_Radio_Connection_MT_initiated 



(DUC-DM-CONNECT-ACK-ARG) 



T_dm_connect_cmpt_mt 



DUC _d m_s e t up _ieq 



(DUC-DM-SETUP-ARG) 



T_dm_setup_int 



D UC_d m_c o nnec t_ ind 



(DUC-DM-CONNECT-ARG) 
D UC_d m_c on iiect_rsp 



RLC_DM_SETUP 



({ peer-mac-id, 
cUd, 

duc-ext-ind, 
c 1-c onn-attr-length , 
duc-descr-list, 
cl-coinmoii-attr) ) 



RLC_DM_CONNECT_ACK 



({peer-mac-id, 
cl-id, 

c 1-c onn-attr-laigth , 
dlcc-descr-list) ) 



T_dm_connect 



DUC_dm_setup_ind 



(DUC-DM-SETUP-ARG) 



DUC_dm_connect_req 



C-DM-CONNECT-ARG) 
cmpt_mt y^ 



T_dm_connect_mt 



D UC_ d m_c on nect_cnf 



CONNECT-ACK-ARG) 



RUC_DM_CONNECT 



cl-conn-attr-laigth, 
duc-descr-list I) 



RUC_DM_SETUP 



( { peer-mac-iJ, 

cMd, 

duc-ect-ind, 

cl-conn-attr-laigth, 

duc-descr-list, 

cl-common-data)) 



RUC_DM_CONNECT 



({peer-mac-id, 
cl-id, 

etc onn-attr-length, 
duc-descr-Kst| ) 



RLC_DM_CONNECT_ACK 



( { peer-mac-rl. 



cl-conn-attr-laigth, 
dlcc-descr-list|) 



DUC_dm_setup_iid 



(DUC-DM-SETUP-ARG) 

DUC_dm_connec t_req 



(DUC-DM-CONNECT-ARG) 



T_dm_c o nnect_ap 



DUC_dm_connect_cnf 



(DUC-DM-CONNECT-ACK-ARG) 



DUC_dm_setup_ieq 



(DUC-DM-SETUP-ARG) 



-^ 



T_dm_setup_ap 



DUC_dm_connect_ind 



(DUC-DM-CONNECT-ARG) 

DUC_d m_co nnec t_rsp 



(DUC-DM-CONNECT-ACK-ARG) 



Direct_Link_Setup_Radio_Connection_completion 



DUC_established 



5.3.7.3 



Diagram 69: Direct Linic Setup procedure - lUIT initiated 



DM DUG Relay Setup (OMT) 



If the Direct Mode is supported, the Relay Release shall be implemented for the AP/CC. 

Even if there is no connectivity between two MTs some facilities might exist for the upper layers to establish a 
connection. In this case, the AP/CC shall relay the data transmission by opening two DiL DUCs for both MTs. The 
RLC_DM_RELAY_SETUP shall be sent by the MX to the AP/CC. The message contains the connection characteristics 
that shall be used by the AP/CC to initiate two DiL Setup procedures. RLC_DM_RELAY_SETUP message shall only 
be initiated by a MT. 
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The AP/CC shall open two direct link DUCs, these connections shall be opened between the MTs and the AP/CC, as 
shown in this figure. In the case MTl has sent the RLC_DM_RELAY_SETUP message, the AP/CC shall respond with 
the RLC_DM_RELAY_SETUP_ACK to MTl. This message shall carry the DLCCJDs and characteristics of the 
DUCs opened between MTl and the AP/CC. If the negotiated characteristics are not acceptable for the MT, it shall 
release the connection using the RLC_DM_RELAY_RELEASE message. 

Referring to the following MSC, the peer-mac-id of the Relay messages from and to MTl shall be set to the MAC ID of 
the MT2. 



MSCDirect_Link_Relay_Setup_Radio_ 


Connection_MT_initiated 












MTLENV 




MT1_RLC 




AP_RLC 


AP_ENV 




MT2_ENV 




MT2_RLC 




































( Associated y 






DUC_dm_relay_setup_req 


) 
RLC_DM_RELAY_SETUP 


DUC_dm_relay_setup_int 


-ARG ) 






T 


( DUC-DM-RELAY-SETUP-ARC 


{peer-mac-id, 
cl-id, 


Z 
dm_relay_setup_mt 


7 


DUC-DM-RELAY-SETUF 


r 


duc-ext-ind, 
cl-conn-attr-length, 
duc-descr-list, 
cl-common-attr) ) 


( 






f 

Direct_Mode_SetLp_Radio_Connection_AP_MT 

V J 
















Direc 


_Mode_SetLp_Radio_Connection_AP_MT 








RL 


DUC_d 
DUC-DM-RELAY-SI 
,C_DM_RELAY_SETUP_ACK 


m_relay_setup_rsp 






;tup-ack-arg 




( {peer-mac -id, 
cl-conn-attr-length, 

dicc-descr-list) ) 

G ) 


/ 
DUC_dm_relay_setup_cnf 


\ 




E 


U(C-DM-RELAY-SETUP-ACK-AR 




/ \ 
( DUC established ^ 

\ / 

















Diagram 70: Relay Setup - MT originated 



Table 93: RLC-DM-RELAY-SETUP 



RLC-DM-RELAY-SETUP-ARG ::= SEQUENCE { 


ric-pdu-type 


RLC-LCH-PDU-TYPE 


peer-mac-id 


MAC-ID 


cl-id 


CL-ID 


duc-ext-ind 


DUC-EXT-IND 


cl-conn-attr-length 


INTEGER(0..31) 


duc-descr-list 


DUC-DESCR-LIST 


cl-common-attr 


CL-COMMON-ATTR } 
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Table 94: RLC-DM-RELAY-SETUP-ACK 



RLC-DM-RELAY-SETUP-ACK-ARG ::= SEQUENCE { 



ric-pdu-type RLC-LCH-PDU-TYPE 

peer-mac-id MAC-ID 

cl-conn-attr-length INTEGER(0..31 ) 

dicc-descr-list DLCC-DESCR-LIST } 



The connections between the AP/CC and both MTs shall be established by the AP/CC initiated DiL DUC Setup 
procedure, where AP/CC acts as one of the MT. 

The following MSC shows this special case. 



MSC Direct_Link_Setup_Radio_Connection_AP_MT 



MT1 ENV 



MT1 RLC 



AP RLC 



AP ENV 



Associated 



DUC_dm_setup_ind 



DUC-DM-SETUP-ARG) 



DUC_dm_connect_req 



(DUC-DM-CONNECT-ARG ) 

X — 

T_d m_con nect_cmpt_m t 

T_d m_con n( j ct_mt 

DUC dm connect cnf "; 



( DUC-DM-CONNECT-ACK-ARG) 



DUC_dm_conn_complete_ind 



duc-dm-connect-complete-arg; 

DUC_dm_conn_complete_rsp 



(DUC-D IVI-CONNECT- COIVI PLETE- ACK 



RLC DM SETUP 



( {peer-mac-id, 

cl-id, 

duc-ext-ind, 

cl-conn-attr-length, 

duc-descr-list, 

cl-common-attr}) 

RLC DM CONNECT 



({peer- mac -id, 
cMd, 

cl-conn-attr-lengtti, 
duc-descr-list} 



RLC DM CONNECT ACK 



{peer -mac -id, 

cMd, 

cl-conn-attr-lengtti, 

dicc-descr-list}) 



-f- 



( DUC-qM-CONNECT-COMPLETE-ARG) 
RiLC DM CONNECT COMPLETE 



{peer-mac-id, 
dicc-id-list}) 



ARG 



RLC DM CONNECT COMPLETtE ACK 



(peer-mac-id ) 



DUC_dm_setup_req 



7 ( DUC-DM-SETUP-ARG) 
T_dm_setup_ap 



DUC dm connect ind 



(DUC-DM-CONNECT-ARG ) 
DUC_dm_connect_rsp 



DUC-DM-CONNECT-ACK-ARG) 



DUC_dm_conn_oomplete_req 



T_dm_connect_cmpt_ap 



DUC_dm_conn_complete_cnf 



(DUC-DM-CONNECT-COMPLETE-ACK-ARG 



DUC established 



Diagram 71 : Direct Linit Setup connection procedure between AP/CC and lUIT, AP/CC initiated 

NOTE: The AP/CC can use AP/CC initiated DiL DUC set up procedure to set up a connection between MTl and 
AP/CC and another one between AP/CC and MT2, then realize the relay between the MTl and MT2. 
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5.3.8 Unicast Direct Link DUG Release 
5.3.8.1 AP/CC initiated DM DUG Release 

This procedure is used to release one or more unicast DiL connections in direct mode. 

The AP/CC shall first indicate to a MT to release the indicated DUCs by a RLC_DM_RELEASE message. The MT 
shall send the RLC_DM_RELEASE_ACK to indicate that the relevant DLCC IDs are released. The AP/CC shall not 
schedule any data to the particular MTs for the particular DLCC IDs after sending the first RLC_DM_RELEASE 

message. 

Referring to the following MSC, the peer-mac-id in the DiL DUC Setup messages from/to MTl shall be set to the MAC 
ID of the MT2 and the peer-mac-id in the DiL DUC Setup messages from/to MT2 shall be set to the MAC ID of the 
MTl. 

The AP/CC shall do the same procedure with the other MT to complete the release of the direct link connections. 

The AP/CC can also act as one of the MTs, in that case the messages between this MT and the AP/CC are exchanged 
internally in the AP/CC. 



MSC Direct_Link_Release_Radio_Connection_AP_initiated 

MT1 ENV MT1 RLC MT2 ENV MT2 RLC 



AP RLC 



AP ENV 



DUC established 



DUC dm release ini3* 



DUC-DM-RE LEASE 
DU C_d m_release_rsp 



(DUC-DM-RELEASE-ACK-ARG 



ARG) 



RLC 



DUC_dm_release_req 



( DUC- 



DM-RELEASE-ARG) 



RLC DM RELEASE 



{ {peer-mac-id, 

release-cause, 

dicc-id-list}) 

DM RELEASE ACK 



({peer-mac-id, 
dicc-id-list} ) 



(DUC-DM-lfiELEASE-ACK-ARG 
Dl|lC_dm_release_req 



( DUC-pM-RELEASE-ARG) 
RLC DM RELEASE 



DUC dm release ind 



( DUC- Diyi- RELEASE- ARG) 

DUC_dm_release _rsp 



( {peer-mac-id, 

release-cause, 

dicc-id-list}) 



(DUC-DM-RELEASE-ACK-ARG ) 

RLC DM RELEASE 



({peer-mac-id, 
dice- id- list} 



(DUC-DM 



X 



T_dm_release_ap 



DUC dm release cnf 



T_dm_release_ap 



ACK 



DUC dm release cnf 



RELEASE-AC K-ARG 



DUC released 



Diagram 72: Direct Linit Release connection procedure - AP/CC initiated 
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Table 95: RLC-DM-RELEASE 



RLC-DM-RELEASE-ARG ::= SEQUENCE 



ric-pdu-type 
peer-mac-id 



RLC-LCH-PDU-TYPE 
MAC-ID 



release-cause RELEASE-CAUSE 
dicc-id-list DLCC-ID-LIST} 



Table 96: RLC-DM-RELEASE-ACK 



RLC-DM-RELEASE-ACK-ARG ::= SEQUENCE 



rIc-pdu-type 
peer-mac-id 
dicc-id-list 



RLC-LCH-PDU-TYPE 

IVIAC-ID 

DLCC-ID-LIST} 



5.3.8.2 



MI initiated DM DUG Release 



A MT may release one or few DiL connections by sending the RLC_DM_RELEASE message to the AP/CC. When the 
AP/CC receives this message, it shall release the connections with the other MT before sending back the 
acknowledgement. In case that the second MT shall send RLC_DM_RELEASE_ACK as a positive acknowledgement, 
the AP/CC shall send the RLC_DM_RELEASE_ACK to the MT that initiated the Release procedure. 

The AP/CC shall not schedule any data to the particular MTs for particular DLCC IDs after receiving the 
RLC_DM_RELEASE message. 

The AP/CC may also act as one of the MTs, in this case the messages between this MT and the AP/CC are exchanged 
internally in the AP/CC. 
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MSC Direct_Link_Release_Radio_Connection_MTJnitated 

MT1 ENV MT1 RLC MT2 ENV MT2 RLC 



DUC_es1ablished 
DU C_dm_rel ease_rec 



AP RLC 



AP ENV 



DUC_dm_release_irjd 

7\RG) 



( DUC-DM-RELEASE 
DU C_dm_rel ease_rsp 



(DUC-DM-RE LEASE -y\CK-ARG ) 



T_dm_release_mt 
FILC DM RELEASE 



( DUC-DM 



(DUC-DM-RELEASE-4RG ) 

RLC DM RELEASE 



^ 



( {peer-mac-id, 

release-cause, 

dicc-id-list}) 



RLC DM RELEASE ACK 



({peer-mac-id, 
dicc-id-list} 



DUC dm release cnf 



RELEASE -ACK-ARG) 



({peer -mac-id, 
release- cause, 
dice- id- list} ) 



(DUC-DM -RE LEASE -4 RG ) 
DUC_dm_release_req 



( DUC-DM-RELEASE-ARG) 



RLC 



( DUC-DM- 
DM RELEASE ACK 



( {peer_mac-id, 
dicc-id-list}) 



DUC dm release ind 



T_dm_release_api 



DUC dm release cnf 



(DUC-DM-RELEASE -ACK-ARG 
DUC_dm_release_rsp 



RELEASE-AC K-ARG) 



DUC released 



5.3.8.3 



Diagram 73: Direct Linit Release connection procedure - IVIT initiated 



DM DUC Relay Release 



Based on the same principle than in the Relay Setup, the MT shall use the RLC_DM_RELAY_RELEASE message to 
send the DLCC IDs to the AP/CC for the Release. The AP/CC shall release the two direct link connections and sent 
back the RLC_DM_RELAY_RELEASE_ACK message as an acknowledgement to the MT. RLC_RELAY_RELEASE 
message shall only be initiated by a MT. 

The AP/CC shall not schedule any data to the particular MTs for these particular DLCC IDs after receiving the 
RLC_DM_RELAY_RELEASE message. 

Referring to the following MSC, the peer-mac-id of the Relay messages from and to MTl shall be set to the MAC ID of 
the MT2. 
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MSC Direct_Lmk_Relay_Release_Radio_Connection_MT_imtiated 

MT1_ENV I I MtFrLC I I ApIrLC I I AP_ENV 



DUC_(iTi_relay_release_]Eq 



(DUC-DM-RELAY-RELEASE- 



ARG ) 

rlc_dm_relay_rele4se 



T_relay_release_mt 



( { peer -mac-id , 
release-cause, 
dlcc-id-listl ) 



DUC_dm_relay_iElease_ind 



(DUC-DM-RELAY-RELEASE- 



Diiect_Link_Release_Radio_Connecrion_AP_MT 



D iEct_Link_Relea!e_Radio_Connection_AP_MT 



( DUC-DM-l^LAY-RELEASE-ACK-ARG) 
RtC_DM_RELAY_RELEASE_AC K 



DUC_dm_ielay_refease_ 



( DUC-DM-RELAY-RE^ASE-ACK-ARG) 



{ {peer-mac-id, 
dice -id-list)) 



DU C_dm_relay_ie lea se_rsp 



DUCjeleased 



Diagram 74: Relay Release - MT originated 
Table 97: RLC-DM-RELAY-RELEASE 



RLC-DM-RELAY-RELEASE-ARG ::= SEQUENCE 



ric-pdu-type RLC-LCH-PDU-TYPE 
peer-mac-id MAC-ID 



release-causeRELEASE-CAUSE 
dicc-id-list DLCC-ID-LIST} 



Table 98: RLC-DM-RELAY-RELEASE-ACK 



RLC-DM-RELAY-RELEASE-ACK-ARG ::= SEQUENCE { 



rIc-pdu-type RLC-LCH-PDU-TYPE 
peer-mac-id MAC-ID 
dicc-id-list DLCC-ID-LIST } 



The connections between the AP/CC and both MTs shall be released by AP/CC initiated DiL DUC Release, where 
AP/CC acts as one of the MT. 

The following MSC shows this special case. 
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MSC Direct_Link_Release_Radio_Connection_AP_MT 

MT1 ENV MT1 RLC 



AP RLC 



AP ENV 



DUG established 



DUG dm release ind 



( DUC-DM-RELEASE-ARG) 



DUC_dm_release_rsp 



(DUC-DM-RELEASE-ACK-ARG 



DUC_dm_release_req 



RLG DM RELEASE 



( {peer-mac-id, 

release-cause, 

dicc-id-list}) 



L DUC-DM-RELEASE-ARG) 



T_dm_release_ap 



RLC DM RELEASE ACK 



({peer-mac-id, 
dicc-id-list} ) 



DUG dm release cnf 



(DUC-DM-RELEASE-ACK-ARG 



DUG released 



Diagram 75: Direct Linl< Release connection AP/CC - IVIT, AP/CC initiated 

NOTE: The AP/CC can use AP/CC initiated DiL DUC Release procedure to release connections between MTl 
and AP/CC and between AP/CC and MT2. 

5.3.9 Unicast Direct Link DUC Modify 
5.3.9.1 AP/CC initiated DM DUC Modify 

This procedure shall be used to modify one or multiple unicast DiL connections. 

The AP/CC shall send a RLC_DM_MODIFY_REQ message to one of the two MTs with the new parameters for the 
selected connections. The MT shall accept the modification by sending the RLC_DM_MODIFY, otherwise, if it does 
not accept the modification, it shall start a DiL Release procedure. The MT shall not modify parameters. The AP/CC 
shall respond to the MT with the RLC_DM_MODIFY_ACK as an acknowledgement to indicate, which DLCC IDs are 
concerned by the change. Referring to the following MSC, the peer_mac_id in the DiL DUC Modify messages from 
and to MTl shall be set to the MAC ID of the MT2 and the peer_mac_id in the DiL DUC Modify messages from and to 
MT2 shall be set to the MAC ID of the MTl. 

The AP/CC can also act as one of the MTs, in this case the messages between this MT and the AP/CC are exchanged 
internally in the AP/CC. 
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MSC Direct_Link_Moclify_Radio_Connection_AP_initiated 



MT1 ENV 



MT1 RCP 



MT2 ENV 



MT2 RCP 



AP RCP 



AP ENV 



DUC Established 



DU C_d m_moclifyreq_ind 



( DUC-DM-MODIFY-F^EaARG) 
PUC_dm_mod ify_req 



(DUC-DM-MODIFY-ARG 



T dm 



modify_cmpt_mt\ 
■_dm_modify_mt 



DUC_dm_modify_cnf 



DUC-DM-MODIFY-ACK-ARG) 



RLC DM MODIFY REQ 



( {peer-mac-id, 

cl-conn-attr-length, 

duc-descr-list}) 



RLC DM MODIFY 



({peer-mac-id, 
cl-oonn-attr -length, 
duc-desa-list} 



RLC DM MODIFY AC< 



( (peer- mac -id, 

cl-conn-attr-length, 

dlcc-descr-listj) 

RLC. 
DUC_dm_modifyreq_ind 



( D(JC-DM-MODIFY-REQ-ARG) 
DUC_d m_mod ify_req 



(DUC-DM-MODIFY-ARG ) 
T_dm_m<:jdify_cmpt_mt ^g 

T_dm_mod if y_m t X — 



RLC 

t 



DUC_dm_modify_cnf 



( DUC-DM-MODIFY-ACK-ARG) 



( DUC 



( DLIC-DM-MODIFY-ACK-A=iG) 



DM MODIFY REC 



(peer-mac-id 
cl-conn-attr-length 
duc-descr-list}) 



RLC DM MODIFY 



({peer-mac-id, 

cl-conn-attr-length, 

duc-desa-list} 



DM MODIFY ACK 



(peer-mac-id, 

cl-conn-attr-length, 

dicc-descr-list}) 



DUC_dm_modifyreq_r€q 



DM-MODIFY-REO-ARG) 



T_dm_modify_req. 



DUC_dm_modify_ind 



(DUC-DM-MODIFY-ARG ) 
DUC_dm_modify_rsp 



DUC_dm_modifyreq. 



DUC-D M-M ODI FY-REp- ARG) 



T_dm_modify_req 



DUC_dm_modify_ind 



1 

(DUC-DM-MODIFY-AFftG 

DUC_dm_modify_r sp 



DUC-DM-MODIFY-ACK-ARG) 



ap 



req 



.ap 



Direct_mode_Modify_Radio_Connection_completion 



DUC established 



Diagram 76: Direct Linit IVIodify procedure - AP/CC initiated 



Table 99: RLC-DI\fl-l\flODIFY-REQ 



RLC-DM-MODIFY-REQ-ARG ::= SEQUENCE ■ 



ric-pdu-type RLC-LCH-PDU-TYPE 

peer-mac-id MAC-ID 

cl-conn-attr-length INTEGER(0..31 ) 

duc-descr-list DUC-DESCR-LIST } 
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Table 100: RLC-DM-MODIFY 



RLC-DM-MODIFY-ARG ::= SEQUENCE ■ 



ric-pdu-type RLC-LCH-PDU-TYPE 

peer-mac-id MAC-ID 

cl-conn-attr-length INTEGER(0..31 ) 

duc-descr-list DUC-DESCR-LIST } 



Table 101: RLC-DM-MODIFY-ACK 



RLC-DM-MODIFY-ACK-ARG ::= SEQUENCE ■ 



rIc-pdu-type RLC-LCH-PDU-TYPE 

peer-mac-id IVIAC-ID 

cl-conn-attr-length INTEGER(0..31 ) 

dicc-descr-list DLCC-DESCR-LIST } 



The AP/CC shall use the same procedure to modify parameters of the other MT. For a secure connection, the 
modifications shall be the same for the two MTs. The AP/CC shall send the RLC_DM_MODIFY_COMPLETE 
message to both MTs to indicate that both MTs are able to perform the modifications. The message shall be used to 
synchronize the two MTs after the modification phase. These messages should be sent in parallel to both MTs. 

The MTs shall perform modifications on DUCs after having received the RLC_DM_MODIFY_COMPLETE message 
from the AP/CC, and they shall send the RLC_DM_MODIFY_COMPLETE_ACK message. 
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MSC Direct_Link_Moclify_Raclio_Connection_completion 



MT1 ENV 



MT1 RCP 



MT2 ENV 



MT2 RCP 



AP RCP 



AP ENV 



T_dm_fnod if y_cmpt_rnt 
DUC 

M 

( DUC-DM-MODIFY-COMPLEfE-ARG) 

DUC_ 

(DUC-DM-MODIFY-COMPLEt£-ACK-ARG ) 



R.C DM MODIFY COMPLETE ACK 



( DUC- DM- 
(DUC-DM-MOD FY- 



RLC_DM_MODIFY_COMPLETE ( DUC-DM-MODIFY-COMPLETE 



( {peer-mac-id, 
dicc-id-list}) 



({peer-mac-id, 
mac- id} ) 



T dm modify cmpt mt 



DUC_dm_modify_cmpl_irKl 



VIODIFY-COMPLETE-ARG) 
DUC_dm_modi1y_cmpi_rs 



COMPLETE-ACK-ARG 

RLC DM MODIFhi' COMPLETE ACK 



DUC_dm_modify_cmpl_cn 



(DUC-DM-MODI 
( DUC-DM 

RLC DM M0DIFY COMPLETE 



l-Y-COMPLETE-ACK-AfiG ) 
DUC_dm_modify_cm pl_req 



M?)DIFY-COMPLETE-AF^G) 



( {peer-mac-id, 
dicc-id-list}) 



DU C_d m_mod if y_cmp 



req 
ARG) 



T_d m_mod if y_cmp t_ap 



T_dm_modify_cmp1_ap 



{{peer -mac-id, 
mac- id } 

D U(t_dm_mod if y_cm pl_cnf 

(DUC-DM-MODII^-COMPLETE-ACK-ARG ) 



Diagram 77: Direct Linit IVIodify connection completion procedure 
Table 102: RLC-DM-MODIFY-COMPLETE 



RLC-DM-MODIFY-COMPLETE-ARG ::= SEQUENCE { 



ric-pdu-type 
peer-mac-id 
dicc-id-list 



RLC-LCH-PDU-TYPE 

MAC-ID 

DLCC-ID-LIST) 



Table 103: RLC-DM-MODIFY-COMPLETE-ACK 



RLC-DM-MODIFY-COMPLETE-ACK-ARG ::= SEQUENCE { 



rIc-pdu-type RLC-SCH-PDU-TYPE 

peer-mac-id MAC-ID 

mac-id MAC- ID } 



NOTE: The AP/CC may be one of the MTs, i.e. MTl or MT2. In this case, the messages shall be sent and 
received internally in the AP/CC. 
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5.3.9.2 MT initiated DIVI DUG IVIodify 



A MT shall initiate a DUC Modify by sending the RLC_DM_MODIFY_REQ message to the AP/CC. This message 
shall contain the new parameters proposed for the modification of one or more connections. The AP/CC shall use the 
RLC_DM_MODIFY message to modify parameters if it is not able to accept those that are proposed. If the MT accepts 
the parameters in the RLC_DM_MODIFY message, the MT shall accept it by sending the RLC_DM_MODIFY_ACK 
message with accepted DLCC IDs. Both MT and AP/CC may reject modifications required by initiating the DiL 
Release procedure. 

The AP/CC shall use the same procedure to modify the parameters of the other MT involved in this direct link. 

Referring to the following MSC, the peer MAC ID in the DiL Due Setup messages from/to MTl shall be set to the 
MAC ID of the MT2 and the peer MAC ID in the DiL Due Setup messages from/to MT2 shall be set to the MAC ID of 
the MTl . If the peer MAC ID is not known to RLC of the initiating MT, then it shall be set to its own value. In that case 
the peer MT is identified in convergence layer container and the AP/CC shall do the mapping. 

The AP/CC can also act as one of the MTs, in this case the messages between this MT and the AP/CC are exchanged 
internally in the AP/CC. 



£75/ 



128 



ETSI TS 101 761-2 VI .3.1 (2002-01) 



MSC Direct_Link_Modify_Radio_Connection_MT_initiated 



MT1 ENV 



MT1 RCP 



MT2 ENV 



MT2 RCP 



AP RCP 



AP ENV 



T_ dm_mo dif y_r eq_mt 



Tj J m_m od if y_cmpt_mt 



DU C_dm_modifyrec^ij eq 
(DUC-DM-MODIFY-REQ-ARG ) 



DUC_dm_modify3fra 



DUC-DM-MODIFY-ARCP 
DUC_d m_mod ify_rsp 



(DUC-DM-MODIFY-ACK-ARG ) 



Associated 



FILC DIVI IVIODIFY REQ 



( {peer-mac-id, 

cl-conn-attr-length, 

duc-desa-listj 



FILC DIVI MODIFY ACK 



DUC 
{ DUC- DM 



({peer-mac-id, 

cl-conn-attr-length, 

duc-desa-list} 



RLC DM MODIFY 



(peer-mac-id, 
cl-conn-attr-length, 
dicc-descr-list} ) 



RLC 



dm_modifyreq_ind 



MODIFY-REO-ARG) 
DUC_dm_modify. ■ 



req 



(DUC-DM-MODIFY-/!.RG 



t^ 



T_dm_modi1/_cmpt_mt^x S7 
T_dm_modify_mt 



D U C_d m_mod if y_cn f>f 



( DUC-D^/|-MODIFY-ACK-ARG) 



(DUC-DM-MODIFY-ACK-ARG 
DUC_dm_modifyreq_req 



(peer-mac-id, 

cl-conn-attr-length, 

duc-desa-listj) 



RLC DM MODIFY 



({peer-mac-id, 

cl-conn-attr-length, 

duc-descr-list} 



{peer-mac-id, 

cl-conn-attr-length, 

dicc-descr-list}) 



DUC_dm_modifyreq_ind 



(DUC-DM-MODIFY-REO-ARG 
DUC_d m_mod ify_req 



DUC-DM-MODIFY-ARG) 



T_dm_modify_ap 



DUC_dm_modify_cn 



{ DUCf-DM-MODIFY-REO-ARG) 
DM MODIFY REQ 



T_dm_modify_req_ap 



DUC_dm_modify_inc 



(pUC-DM-MODIFY-ARG 
DUC_dm_modify_rsp 



( DUC-DM-MODIFY-ACK-ARG) 
RLC DM MODIFY ACK 



) 



Direct_mode_Modify_Radio_Connection_completion 



DUC established 



Diagram 78: Direct Linl< IVIodify procedure - IVIT initiated 

After receiving RLC_DM_MODIFY_ACK the AP/CC shall send the RLC_DM_MODIFY_COMPLETE message to 
synchronize both MTs and also to indicate, which connections will change their characteristics. If both MTs do not 
accept the same parameters, the AP/CC shall release the connections. Then after receiving these messages, both MTs 
shall respond with RLC_DM_CONNECT_COMPLETE_ACK message. 
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5.3.9.3 



DM DUG Relay Modify 



The principle of this procedure is the same than in the Relay Setup, the MT will ask the AP/CC to modify the two direct 
link connections previously opened between AP/CC and MTl, and between MT2 and AP/CC. The DLCC IDs used 
shall be those of the connections between the AP/CC and the MT that sent the RLC_DM_RELAY_MODIFY message. 
The AP/CC shall respond with the RLC_DM_RELAY_MODIFY_ACK containing the modified DLCCJDs as an 
acknowledgement. This list shall be empty, if the AP/CC or the other MT have not accepted the requested 
characteristics. 

The RLC_DM_RELAY_MODIFY message shall only be initiated by an MT. Referring to the following MSC, the 
peer-mac-id of the Relay messages from and to MTl shall be set to the MAC ID of the MT2. 



MSC Direct_Link_Relay_Modify_Radio_Connection_MT_initiated 



D UC_(in_relay_inodify_req 



(DUC-DlVtRELAY-M0DIFY-4RG ) 

RLC_DM_RELAYJV10D1FY 



T_re]ay_modify_mt 



1 3i rec t_Link_Modity_Rad b_C amection_AP_MT 



( { peer -mac-id , 
c 1-conn- attr-length, 
duc-descr-lst} ) 



DUC_dm_relay_modify_inc 



(DUC-DM-RELAY-MODIFY-ARG ) 



Direct_Lkk_Modify_Radio_Comection_APJVIT 



DUC_dm_relay_modify_crf 



( DUC-DM-RELAY-MODlPl'-ACK-ARG) 



DUC_dm_relay_modify_rsp 



( DUC-DM-RJ!LAY-M0D1FY-ACK-ARG) 



RLC_DM_RELAYJV10D1FY_ACK 



( {peer-mac -id, 

cl-conn-attr- length, 

dlcc-descr-list}) 



DUC_modified 



Diagram 79: Direct Linl< Relay lUlodify procedure - lUIT initiated 



Table 104: RLC-DIVI-RELAY-MODIFY 



RLC-DM-RELAY-MODIFY-ARG ::= SEQUENCE { 



ric-pdu-type RLC-LCH-PDU-TYPE 

peer-mac-id MAC-ID 

cl-conn-attr-length INTEGER(0..31 ) 

duc-descr-list DUC-DESCR-LIST } 
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Table 105: RLC-DM-RELAY-MODIFY-ACK 



RLC-DM-RELAY-MODIFY-ACK-ARG ::= SEQUENCE { 



ric-pdu-type RLC-LCH-PDU-TYPE 

peer-mac-id MAC-ID 

cl-conn-attr-length INTEGER(0..31 ) 

dicc-descr-list DLCC-DESCR-LIST } 



The connections between the AP/CC and both MTs shall be modified by AP/CC initiated DiL DUC Modify procedure, 
where AP/CC acts as one of the MT. 

The following MSC shows this special case. 

MSCDirect_Link_Modify_Radio_Connection_AP_MT 



DUC_Establshed 



RLC_DM_MODIFY_REQ 



DUC dmmodifyreqind 



(D UC-DM -MO DIF Y-REQ - ARC ) 
DUCdmmodifyreq 



( [ peer-mac -id, 

cl-conn-attr-length, 

dnc-descr-list]) 



RLC_DM_MODIFY 



^ 



(DUC-DM-MODIFY-ARG) 

T_dm_modify_cmpt_mt 

T_dm_riodify_mt 



DUC_dni_modify_cnf 



([peer-mac-id, 
c 1-c o nn-attr-lai gth , 
duc-descr-list} ) 



RL C _ DM _M O DIF Y _ AC K 



(DUC-DM-MODFY-ACK-ARG) 



( { peer-mac -id, 

cl-conn-attr-length, 

dlcc-descr-list I) 

RLC_DM_MODIFY_COMPLETE 



D UC _ d m_ m o d ify _c mp 1_ ind 



([peer-mic-id, 
dlcc-id-list}) 



(DUC-DM -MODIFY -COM? LET E-ARG) 
D UC_ d ni _ni o d if y_ c ni p 1_ rs p 



RLC_DM_MODIFY_COMPLETE_ACK 



(DLC-DM-MODFY-COMPLETE-ACK-ARG) 



( j peer-mac-id | 



DUC _d m_niod ifyreq_req 



(DUC-DM-MODIFY-REQ-ARG) 

T_dm_modify_req_ap 



•-DUC_dm_modify_hd 



(DUC-DM-MODFY-ARG) 

DUC_dm_modify_rsp 



({DUC-DM-MODIFY-ACK-ARG}) 
DUC_dm_modify_ciiipl_req 



(DUC-DM-MODIFY-COMP LET E-ARG) 



T_dm_modify_cmpt_i^ 



D UC _ d m_ 111 o dif y_ c mp 1_ c nf 



(DUC-DM-MODIFY-COMPLETE-ACK-ARG) 



DUC_established 



Diagram 80: Direct Link l\/lodify connection AP/CC - l\/IT, AP/CC initiated 
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5.3.1 Unicast Direct Link DUG Reset 

Witii tiie reset procedure the ARQ instance and related timers of one or more unicast DiL DUCs siiall be reset to tiieir 
initial state. The DUC characteristics as agreed on Setup or latest modifications will be maintained. The direct link 
Reset procedure shall be initiated by sending the RLC_DM_RESET message including the DLCC ID(s) of the DUCs. 
The receiving entity (MT and/or AP/CC) shall acknowledge the Reset by responding with RLC_DM_RESET_ACK 
indicating the corresponding DLCC ID(s). 

NOTE: These messages may not be used for connections using FCA or PSA. 



5.3.10.1 



AP/CC initiated DM DUC Reset 



This procedure allows to reset one or more unicast DiL connections. The AP/CC should stop scheduling data to the 
particular MT after sending the RLC_DM_RESET message. 

To reset the DUCs in the MT, the AP/CC shall send the RLC_DM_RESET message. The MT shall send the 
RLC_DM_RESET_ACK as positive acknowledgement, if the relevant DLCC_ID has been reseted. 

The AP/CC shall do the same procedure with the other MT to complete the Reset of the direct mode connections. 



MSC Direct_Link_Reset_Radio_Connection_AP_initated 



DUC_established 













RLC_DM_RESET 


DUC_dm_reset_req 






^ 












DUC_dm_iEset_ind 




( {mac-id. 






({peer-mac-id, 
dlcc-id-Bsti) 


X7 peer-mac-id. 






^ 


^ dlcc-id-list[) 


















( {mac-id. 


















peer-mac-id. 


















dfcc-id-lKt|) 






T_dm_resa_^ 












DUC_dm_reset_cnf 


RLC_DM^RESET_ACK 






















(|mac-id, 
peer-mac-id. 






/ 






({peer-mac-id, 






/ 












dbc-id-list) ) 


dtc-id-lKt[ ) 


DUC_dm_reset_cnf 






















({mac-id. 
















peer-mac-id, 
















dlcc-id-teti ) 






DUC_ 


dm_iEset_ind 






RLC_DM_RESET 


DUC_dm_reset_^req 






( |mac-id. 










({peer-mac-id, 
dlcc-id-list|) 


^7 peer-mac-id. 






^ 


^ dlcc-id-Ust|) 
















( (mac-id, 
peer-mac-id. 










T_dm_reset_ap 








dlcc-id-Ust|) 
















DUC_dm_ieset 


_rsp 


RLC_DM_RESET^ACK 






\ 


/ 






(|mac-H, 
peer-mac -id, 
dlcc-id-list[ ) 








(Ipeer-mac-id, 










/ 


\ 










dlcc-id-Kst[ ) 






DUC_dm_reset_cnf 






















(|mac-id, 
















pea--mac-id. 
















dlcc-id-Kst| ) 





DUC_established 



Diagram 81 : Direct Link Reset connection procedure - AP/CC initiated 
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Table 106: RLC-DM-RESET 



RLC-RESET-ARG ::= SEQUENCE { 



ric-pdu-type 
peer-mac-id 
dicc-id-list 



RLC-LCH-PDU-TYPE 

MAC-ID 

DLCC-ID-LIST} 



Table 107: RLC-DM-RESET-ACK 



RLC-RESET-ACK-ARG ::= SEQUENCE { 



rIc-pdu-type 
peer-mac-id 
dicc-id-list 



RLC-LCH-PDU-TYPE 

IVIAC-ID 

DLCC-ID-LIST} 



5.3.10.2 



MT initiated DM DUG Reset 



A MT shall use the RLC_DM_RESET message to reset a connection. When the AP/CC receives this message, it shall 
reset the connection with the other MT before sending back the RLC_DM_RESET_ACK. In case the second MT sends 
the RLC_DM_RESET_ACK as a positive acknowledgement, the AP/CC shall acknowledge to the MT that has initiated 
the reset procedure. 

The AP/CC shall reset the ARQ instance just after receiving RLC_DM_RESET message. TxBoW and RxBoW of the 
corresponding DUCs shall be reset to zero both in the MT and the AP/CC. 



MSC Direct Mode Reset Radio Connection MT initated 



DUC_eMabli!,he<l 



( (mac-id, 
peer-mac-id, 
dlcc-id-list}) 

etrsp 



((mac-il, 
peer-mac -il, 
dlcc-id-list} ) 



RLC_DM_RESET_ACK 



({peer-mac-id, 
dlcc-id-litl ) 



DUC_dm„reset_req 



({mac-id, 
peer-mac-id, 
dlcc-id-list) ) 



T_dm_reset_mt 



DUC_dm_reset_cnf 



( {mac-id. 
peer-mac-id, 
dlcc-id-Ist )} 



RLC_DM_RESET 



({peer-mac-id, 
dlcc-id-list I ) 



({mac-id, 
peer-mac-id, 
dlcc-id-lBt) ) 



DUC_dm_reset_req 



RLC_DM_RESET 



( {peer-mac-id, 
dlcc-id-list}) 



( {mac-id, 
peer-mac-id, 
dlcc-id-list}) 



T_dm_reset_ap 



DUC_dm_reset_cnf 



RLC_DM_RESET_ACK 



({mac-id, 

peer-mac-id, 
({peer-mac-id. jiec-id-lit} ) 
dlcc-id-list)) 



DUC_establislied 



Diagram 82: Direct Link Reset connection procedure - MT initiated 
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5.3.1 1 Multicast Direct Linl< 



Multicast DUCs are implicitly set up by Group Join procedure after the Association procedure, as defined in 
clause 5. 3. 11. The MAC IDs and DLCC IDs reserved for multicast connections are defined in TS 101 761-1 [5]. 

5.3.12 Broadcast Direct Linl< 

Broadcast DUCs are implicitly set up by Broadcast Join during the association procedure, as defined in clause 5.1.5. 
The MAC IDs and DLCC IDs reserved for broadcast connections are defined in TS 101 761-1 [5]. 

5.3.13 Unicast Test Mode DUG Setup (OAP/OMT) 

Unicast test mode connection can be requested both by the AP and by the MT using the RLC_TEST-MODE_SETUP 
message. In the message the selected DLCC ID and all test mode characteristics shall be included. 

The RLC_TEST-MODE_SETUP message shall be used for conformance test reasons only. For activation of the test 
modes via the RLC_TEST-MODE_SETUP messages, entering the test mode shall be locally enabled for security and 
conformance testing reasons. The implementation of this local enable is not subject to standardisation. If the test mode 
of the device under test (DUT) is not enabled locally, the RLC_TEST-MODE_SETUP messages shall be rejected by 
the device under test in sending the RLC_RELEASE message and continue with the Release procedure, as described in 
clause 5.3.2. 

If the receiver of the RLC_TEST_MODE_SETUP message being either the AP or the MT as the device under test is 
not able to accept the proposal made by the sender being the conformance tester, it shall send an 
RLC_TEST_MODE_CONNECT message containing the receiver's proposal. To accept the proposal made by the 
sender, the receiver shall repeat the proposal of the sender in the RLC_TEST_MODE_CONNECT message. In order to 
reject the RLC_TEST_MODE_SETUP the receiver shall send RLC_RELEASE message and continue with the Release 
procedure, as described in clause 5.3.2. 

If the sender accepts the receiver's proposal sent in the RLC_TEST_MODE_CONNECT message, the sender shall 
respond with RLC_TEST_MODE_CONNECT_ACK message. Otherwise the sender shall send RLC_RELEASE 
message and continue with the Release procedure, as described in clause 5.3.2. 

The test mode shall be activated after the test mode preparation time (T_prepare_test_mode_mt/ap), which starts from 
the frame the RLC_CONNECT_ACK is received (the next frame is number 1, etc.). 

In order to release the current test mode connection, either the AP or the MT can send RLC_RELEASE message and 
continue with the Release procedure, as described in clause 5.3.2. 

5.3.1 3.1 AP Initiated Test IVIode DUG Setup 

The AP can send RLC_TEST_MODE_SETUP message in order to establish a unicast test mode connection with the 
MT as the device under test. In the message the selected DLCC ID and all test mode characteristics shall be included. 
The AP sender shall not transmit downlink traffic to the MT until the RLC_TEST_MODE_CONNECT message is 
received. 

If the AP accepts the MT's proposal included in the RLC_TEST_MODE_CONNECT message, the AP shall respond 
with RLC_TEST_MODE_CONNECT_ACK message. 

At the reception of the RLC_TEST_MODE_CONNECT message, the AP shall: 

Discard all data in its reception buffer and optionally discard all data in its transmission buffer (the decision is 
vendor specific). 

- Set TxBoW and RxBoW to 0. 

If the sender and/or receiver are in flow control state, exit the flow control state. 

Clear all other ARQ state information, i.e. acknowledgement bitmaps, and enter the unacknowledged mode. 

- Set the DUC characteristics as included in the RLC_TEST_MODE_CONNECT message. 
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Allocate the necessary radio resource for the requested test LCHs. Preferably but optionally the fixed slot 
allocation (FSA) mode should be negotiated during the test mode DUC setup. 

If the AP does not accept the MT's proposal sent in the RLC_TEST_MODE_CONNECT message, the AP shall send 
the RLC_RELEASE message and continue with the Release procedure, as described in 5.3.2. 

If the MT is not able to accept the proposal made by the AP in the RLC_TEST_MODE_SETUP message completely, it 
shall send RLC_TEST_MODE_CONNECT message containing the MT's proposal. To accept the proposal made by the 
AP, the MT shall repeat the proposal of the AP in the RLC_TEST_MODE_CONNECT message. The MT sender shall 
not transmit uplink traffic to the AP until the RLC_TEST_MODE_CONNECT_ACK message is received. 

At the transmission of the of the RLC_TEST_MODE_CONNECT message, the MT shall: 

Discard all data in its reception buffer and optionally discard all data in its transmission buffer (the decision is 
vendor specific). 

- Set TxBoW and RxBoW to 0. 

If the sender and/or receiver are in flow control state, exit the flow control state. 

Clear all other ARQ state information, i.e. acknowledgement bitmaps and rtt awareness for resource request, and 
enter the unacknowledged mode. 

- Set the DUC characteristics as included in the RLC_TEST_MODE_CONNECT message. 

If the MT is not able to accept the proposal made by the AP and can not send an alternative to the AP, the MT shall 
send an RLC_RELEASE message and continue with the Release procedure, as described in clause 5.3.2. 
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MSC Setup_Test_Mode_Connection_mobile_terminated 

MT ENV I MT RLC I AP RLC 



AP ENV 



DUC_test_mode_setup_ind 



( DUC-TEST-MODE-SETUP-ARG 
D U C_test_m od e_co n n ect_req 



( DUC-TEST-MODE- 
CONNECT-ARG ) 



T test mode connect mt 



T_prepare_.test_mode_mt 

]g DUC_test_mode_connect_cnf 



( DUC-TEST-MODE- 
CONNECT-ACK-ARG ) 



Associated 



RLC TEST MODE SETUP 



( {test-mode, 

test-mode-duc-fwbw-descr}) 



RLC TEST MODE CONNECT 



{test-mode, 
test-mode-duc-fwbw-descr } 



RLC TEST MODE CONNECT ACK 



( {test-mode, 
test-mode-dlcc-fwbw-descr} ) 



DUC_test_mode_setup_req 



DUC-TEST-MODE- 
SETUP-ARG ) 



T_test_mode_setup_ap 



DUC test mode connect ind 



( DUC-TEST-MODE- 
CONNECT-ARG ) 

DUC_test_mode_connect_rsp 



( DUC-TEST-MODE- 
CONNECT-ACK-ARG 



T prepare_test_mode_mt 



DUC test mode established / test mode activated 



Diagram 83: Mobile terminated test mode connection Setup procedure 
Table 108: RLC-TEST-MODE-SETUP 



RLC-TEST-MODE-SETUP-ARG : 


:= SEQUENCE { 


ric-pdu-type 


RLC-LCH-PDU-TYPE, 


test-mode 


TEST-MODE, 


test-mode-duc-fwbw-descr 


TEST-MODE-DUC-FWBW-DESCR } 



Table 109: RLC-TEST-MODE-CONNECT 



RLC-TEST-MODE-CONNECT-ARG ::= SEQUENCE { 
ric-pdu-type RLC-LCH-PDU-TYPE, 

test-mode TEST-MODE, 

test-mode-duc-fwbw-descr TEST-MODE-DUC-FWBW-DESCR } 



Table 110: RLC-TEST-MODE-CONNECT-ACK 



RLC-TEST-MODE-CONNECT-ACK-ARG ::= SEQUENCE { 
ric-pdu-type RLC-LCH-PDU-TYPE, 

test-mode-dicc-fwbw-descr TEST-MODE-DLCC-FWBW-DESCR } 
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5.3.1 3.2 MT Initiated Test IVIode DUG Setup 

The MT can send RLC_TEST_MODE_SETUP message in order to establish unicast test mode connections with the AP 
as the device under test. In the message the selected DLCC ID and all test mode characteristics shall be included. The 
MT sender shall not transmit uplink traffic to the AP until the RLC_TEST_MODE_CONNECT message is received. 

If the MT accepts AP's proposal sent in the RLC_TEST_MODE_CONNECT message, the MT shall respond with 
RLC_TEST_MODE_CONNECT_ACK message. 

At the reception of the RLC_TEST_MODE_CONNECT message, the MT shall: 

Discard all data in its reception buffer and optionally discard all data in its transmission buffer (the decision is 
vendor specific). 

- Set TxBoW and RxBoW to 0. 

If the sender and/or receiver are in flow control state, exit the flow control state. 

Clear all other ARQ state information, i.e. acknowledgement bitmaps and rtt awareness for resource request, and 
enter the unacknowledged mode. 

- Set the DUC characteristics as included in the RLC_TEST_MODE_CONNECT message. 

If the AP is able to accept the proposal made by the MT in the RLC_TEST_MODE_SETUP message completely, it 
shall send RLC_TEST_MODE_CONNECT message containing the MT's proposal. The AP sender shall not transmit 
downlink traffic to the MT until RLC_TEST_MODE_CONNECT_ACK message is received. 

If the AP does not accept the proposal made by the MT completely, it shall send an RLC_TEST_MODE_CONNECT 
message with the AP's new proposal. If the MT does not accept the AP's proposal sent in the 
RLC_TEST_MODE_CONNECT message, the MT shall send the RLC_RELEASE message and continue with the 
Release procedure, as described in clause 5.3.2. 

At the transmission of the of the RLC_TEST_MODE_CONNECT message, the AP shall: 

Discard all data in its reception buffer and optionally discard all data in its transmission buffer (the decision is 
vendor specific). 

- Set TxBoW and RxBoW to 0. 

If the sender and/or receiver are in flow control state, exit the flow control state. 

Clear all other ARQ state information, i.e. acknowledgement bitmaps, and enter the unacknowledged mode. 

- Set the DUC characteristics as included in the RLC_TEST_MODE_CONNECT message. 

Allocate the necessary radio resource for the requested test LCHs. Preferably but optionally the fixed slot 
allocation (FSA) mode should be negotiated during the test mode DUC setup. 

If the AP is not able to accept the proposal made by the MT and can not send an alternative to the MT, the AP shall 
send an RLC_RELEASE message and continue with the Release procedure, as described in clause 5.3.2. 
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MSC Setup_Test_Mode_Connection_mobile_terminated 



MT ENV 



MT RLC 



AP RLC 



AP ENV 



DUC_test_mode_setup_req 



( DUC-TEST-MODE- 
SETUP-ARG ) 



T_test_mode_setup_mt 



DUG test mode connect ind 



Associated 



RLC TEST_MODE_SETUP 



( {test-mode, 
test-mode-duc-fwbw-descr} ■. 



"*• DUC_test_mode_setup_ind 



( DUC-TEST-MODE- 
GONNECT-ARG ) 



D U C Jest_m ode_con nect_rsp 



( DUC-TEST-MODE- 
SETUP-ARG ) 

DUC_test_mode_connect_req 



RLC TEST MODE CONNECT 



( {test-mode, 
test-mode-duc-fwbw-descr } ) 



( DUC-TEST-MODE- 
CONNECT-ACK-ARG ) 



T_test_mode_connect_ap 



( DUC-TEST-MODE- 
CONNECT-ACK-ARG ) 



RLC TEST MODE CONNECT ACK 



T_prepare_test_m ode_ ap 



( {test-mode, 
test-mode-dlcc-fwbw-descr 1 



T_prepareJ_test_mode_ap 
DUC test mode_connect_cnf 



( DUC-TEST-MODE- 
CONNECT-ARG 



DUC test mode established /test mode activated 



Diagram 84: Mobile originated test mode connection Setup procedure 



6 Timers and repetitions of RLC messages 

RLC messages use DLC unacknowledged mode and they use the most robust PHY mode. Retransmission at the RLC 
level shall be used to ensure the receiving of the messages. When a message is sent, a timer function shall be activated 
at the sender. If a reply to the sent message is not received within the time set for the timer function, the sender of the 
message shall send the message again (retransmit). The maximum number of retransmissions shall be 4, that is, the 
maximum number of transmissions shall be 5. The receiver of the message that is sent by the sender, shall respond 
within the time set for the timer function at the sender. The exception for this scheme are the unacknowledged broadcast 
messages (e.g. RLC_CHANGE_FREQUENCY), which may be sent more often and without specific limits in 
retransmission timers. 

The timer values differ within wide ranges, both for implementation reasons and, for certain messages, due to delays in 
the fixed network. A message should not be retransmitted until the timer function has expired. For the case of large 
timer function values, this would mean that retransmission could take a long time (the number of retransmissions times 
the timer value). To avoid that to happen, the timer function shall work as follows. For all timer values, an ordinary 
timer shall be started at the sending of a message, supervising the arrival of the ordinary acknowledgement to the sent 
message. For long and medium timer values, an extra timer (short timer value) may be started. The function of the extra 
timer shall be to supervise the retransmission procedure of the sender. A reply message, RLC_PROCEEDlNG, shall be 
used as acknowledgement and to stop the extra (short) timer. The total retransmission time is then the number of 
retransmissions times the short time instead of the number of retransmission times the medium or long time. 

The use of the extra timer should be used for time critical functions like association/handover. 
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The RLC_PROCEEDING message with the short extra timer shall also be used when a message has no answer to 
secure that messages will be retransmitted when needed. 



MSC Repeting_signals 



Sigial_ ready 



Signal_A_req 



T_long_or_medium ^2— 



T_short ^- 



Signal_A_req 



T_long_or_rrEdium ^^ 



T_short ^ 



Signal_A_req 



T_long_a"_medium ^Z- 



T_stortZV" 
T_shDrt ^ 



S ignal_A_ind 



SIGNAL_A_ACK 



( { challaige-to-mt ! ) 



S ignal_A_ind 



RLC_PR0CEED1NG 



SIGNAL_A_ACK 



SIGNAL_A_ACK 



Sigial_transmitEd 



Signal_A_rsp 



Signal_A_rsp 



Diagram 85: Repetition and proceeding procedure 
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Table 111 : RLC-PROCEEDING 



RLC-PROCEEDING-ARG ::= SEQUENCE { 


ric-pdu-type 


RLC-SCH-PDU-TYPE 


sch-lch 


SCH-LCH 


no-support-pdu 


-type PDU-TYPE-CHOICE 


extension-type 


EXTENSION-TYPE 


mac-id 


MAC-ID } 



PDU for unsupported messages 



The presentdocument contains several optional functions and there may be new versions and extensions in future. 
Therefore, there is no confirmation that both the MT and AP support all the messages they receive. In the case that the 
MT or the AP receives an RLC message that it does not support, it shall send the RLC_NO_SUPPORT message. 

Table 112: RLC-NO-SUPPORT 



RLC-NO-SUPPORT-ARG ::= SEQUENCE { 


ric-pdu-type 


RLC-SCH-PDU-TYPE 


sch-icti 


SCH-LCH 


no-support-pdu 


-type PDU-TYPE-CHOICE 


extension-type 


EXTENSION-TYPE 


mac-id 


MAC-ID } 



8 Primitives 

8.1 Primitive types 

Four primitive types may be used: 

req (request), for a higher layer to request service from a lower layer; 

cnf (confirm), for the layer providing the service to confirm that the activity has been completed; 

ind (indication), for a layer providing a service to notify the next higher layer of any specific service related 
activity; 

rsp (response), for a layer to acknowledge receipt of an indication primitive from the next lower layer. 

The defined types for each category of primitive are shown as a list in curly brackets. 

NOTE: These primitives are defined only for the purpose of describing layer-to-layer interactions. The primitives 
are defined as an abstract list of parameters, and their concrete realization may vary between 
implementations. No formal testing of primitives is intended. The following primitive definitions have no 
normative significance. 
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8.2 Primitives to the Convergence Layer, DLC C-SAP 

This clause summarizes the primitives between the convergence layer and the RLC layer. 



Convergence Layer 



DLC C-SAP 
Primitives 



Radio 
Resource 
jDontroL 




DLC 

Connection 

^Control^ 



RLC Primitives 



RLC protocol 



Figure 9 

The primitives at the DLC C-SAP have a correspondence to a subset of the RLC primitives. The parameters used in the 
primitives at the DLC C-SAP are equal to or a subset of the RLC parameter. 

At the AP the MAC ID is used to distinguish between different RLC instances. In the MT only one RLC instance exist. 

The following DLC C-SAP primitives with their corresponding RLC primitives exist: 



DLC C-SAP primitive 


RLC primitive 


DLC_SETUP - { req, ind }; 


DUC SETUP -{ req, ind }; 
DM SETUP - { req, ind }; 


DLC_CONNECT - { req, cnf, ind, rsp }; 


DUC_CONN - { req, cnf, ind, rsp }; 
DM CONN - { req, cnf, ind, rsp }; 


DLC_RELEASE - { req, cnf, ind, rsp }; 


DUC_RELEASE - { req, cnf, ind, rsp }; 
DM RELEASE - { req, cnf, ind, rsp }; 


DLC_MODIFY - { req, cnf, ind, rsp }; 


DUC_MODIFY - { req, cnf, ind, rsp }; 
DM MODIFY - { req, cnf, ind, rsp }; 


DLC MULTICAST JOIN - { req, cnf, ind, rsp }; 


ACF GROUP JOIN - { req, cnf, ind, rsp }; 


DLC MULTICAST LEAVE - { req, ind }; 


ACF GROUP LEAVE - { req, cnf, ind, rsp }; 


DLC CL BROADCAST JOIN - { req, cnf, ind, rsp }; 


ACF CL BROADCAST JOIN - {req, cnf, ind, rsp}; 


DLC INFO TRANSFER - { req, cnf, ind, rsp }; 


ACFJNFO - { req, cnf, ind, rsp }; 



NOTE: One DLC C-SAP primitive may correspond to one of possibly several RLC primitives. It is the task of the 
RLC functions (ACF and DCC) to control the relation between DLC C-SAP primitives and the RLC 
primitives. The RLC functions invoke the RLC primitives with appropriate parameters. (E.g. a request 
from the CL to setup 8 connections may result in 2 subsequent connection setup sequences at the RLC 
level, each setting up 4 connections.) 
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Annex A (normative): 

PDU type and Transfer Syntax Tables 

A.1 RLC PDU type 

The MT and AP columns indicate, whether the PDU is Mandatory or Optional to implement in the MT and AP. The 
PDU can be mandatory for both the sender and the receiver or the other peer only. If a PDU is mandatory for the sender, 
the sender shall be able to encode the PDU and send it at the correct time according to the present document. If the PDU 
is mandatory for the receiver, it shall be able to decode the PDU and perform the requested actions according to the 
present document. If the PDU is optional, the sender may not be able to encode or use it. If the PDU is optional the 
receiver may not be able to decode the PDU, but the receiver shall be able send corresponding RLC_NO_SUPPORT 
message. 



A.1.1 LCH RLC PDU type 



Table A.1 : RLC ACF LCH PDU messages 



LCH PDU type 


RLC message name 


MT 


AP 


(0000 0001)1 


RLC RBCH ASSOCIATION 


M 


M 


2 


RLC LINK CAPABILITY 


M 


M 


3 


RLC LINK CAPABILITY ACK 


M 


M 


4 


RLC KEY EXCHANGE MT 1 


M 


M 


5 


RLC KEY EXCHANGE MT 2 


M 


M 


6 


RLC KEY EXCHANGE AP 1 


M 


M 


7 


RLC KEY EXCHANGE AP 2 


M 


M 


8 


RLC_AUTHENTICATION 


M 


M 


9 


RLC_AUTHENTICATION_MT 


M 


M 


10 


RLC_AUTHENTICATI0N_AP_1 


M 


M 


11 


RLC_AUTHENTICATI0N_AP_2 


M 


M 


12 


RLC_AUTHENTICATI0N_AP_3 


M 


M 


13 


RLC_AUTHENTICATI0N_ACK_1 


M 


M 


14 


RLC_AUTHENTICATI0N_ACK_2 


M 


M 


15 


RLC_AUTHENTICATI0N_ACK_3 


M 


M 


16 


RLC DM COMMON KEY DISTR 








17 


RLC DM COMMON KEY DISTR ACK 








18 


RLCJNFO 








19 


RLC INFO ACK 








20 


RLC UNICAST KEY REFRESH 


M 





21 


RLC UNICAST KEY REFRESH ACK 


M 





22 


RLC COMMON KEY REFRESH 


M 





23 


RLC COMMON KEY REFRESH ACK 


M 





24 


RLC GROUP JOIN 








25 


RLC GROUP JOIN ACK 








26 


RLC GROUP JOIN NACK 








27 


RLC GROUP LEAVE 








28 


RLC GROUP LEAVE ACK 








29 


RLC CL BROADCAST JOIN 








30 


RLC CL BROADCAST JOIN ACK 








31 


RLC CL BROADCAST LEAVE 








32 


RLC CL BROADCAST LEAVE ACK 
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Table A.2: RLC RRC LCH PDU messages 



LCH PDU type 


RLC message name 


MT 


AP 


64 


RLC_RADIO_HANDOVER_COMPLETE 








65 


RLC_HANDOVER_ASSOCIATION 








66 


RLC_HANDOVER_LINK_CAPABILITY_ACK 








67 


RLC_NW_SIGNALLING_HANDOVER 








68 


RLC_NW_SIGNALLING_HANDOVER_ACK 








69 


RLG_NETWORK_HANDOVER_COMPLETE 








70 


RLC HO INFO DISTRIBUTION 








71 


RLC DPS MEASUREMENT COMPLETE REOUEST 
MENT COMPLETE REOUEST 


M 


M 


72 


RLC DPS MEASUREMENT PERCENTILES REQU 
EST 


M 


M 


73 


RLC DPS MEASUREMENT SHORT REOUEST 


M 


M 


74 


RLC DPS REPORT COMPLETE 


M 


M 


75 


RLC DPS REPORT PERCENTILES 


M 


M 


76 


RLC DPS REPORT SHORT 


M 


M 



Table A.3: RLC DUCC LCH PDU messages 



LCH PDU type 


RLC message name 


MT 


AP 


128 


RLC SETUP 


M 


M 


129 


RLC CONNECT 


M 


M 


130 


RLC CONNECT ACK 


M 


M 


131 


RLC RELEASE 


M 


M 


132 


RLC RELEASE ACK 


M 


M 


133 


RLC MODIPY REO 








134 


RLC MODIPY 








135 


RLC MODIPY ACK 








136 


RLC RESET 


M 


M 


137 


RLC RESET ACK 


M 


M 


138 


RLC DM SETUP 








139 


RLC DM CONNECT 








140 


RLC DM CONNECT ACK 








141 


RLC DM CONNECT COMPLETE 








143 


RLC DM RELAY SETUP 








144 


RLC DM RELAY SETUP ACK 








145 


RLC DM MODIPY REO 








146 


RLC DM MODIPY 








147 


RLC DM MODIPY ACK 








148 


RLC DM MODIPY COMPLETE 








149 


RLC DM RELAY MODIPY 








150 


RLC DM RELAY MODIPY ACK 








151 


RLC DM RELEASE 








152 


RLC DM RELEASE ACK 








153 


RLC DM RELAY RELEASE 








154 


RLC DM RELAY RELEASE ACK 








155 


RLC DM RESET 








156 


RLC DM RESET ACK 








157 


RLC TEST MODE SETUP 








158 


RLC TEST MODE CONNECT 








159 


RLC TEST MODE CONNECT ACK 
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A.1.2 SCH RLC PDU type 



Table A.4: RLC ACF SCH PDU messages 



SCH PDU type 


RLC message name 


MT 


AP 


(0000 0001) 1 


RLC RBCH ASSOCIATION REQ 





M 


2 


RLC MAC ID ASSIGN 


M 


M 


3 


RLC MAC ID ASSIGN ACK 


M 


M 


4 


RLC MAC ID ASSIGN NACK 


M 


M 


5 


RLC COMMON KEY ACTIVATE 


M 





6 


RLC DISASSOCIATION 


M 


M 


7 


RLC DISASSOCIATION ACK 


M 


M 


8 


RLC PROCEEDING 


M 


M 


9 


RLC UNICAST KEY ACTIVATE 


M 






Table A.5: RLC RRC SCH PDU messages 



SCH PDU type 


RLC message name 


MT 


AP 


64 


RLC_SECTOR_HANDOVER_REQUEST 








65 


RLC_SECTOR_HANDOVER_ACK 








66 


RLC_HANDOVER_NOTIFY 








67 


RLC_HANDOVER_REQUEST 








68 


RLC HANDOVER REOUEST NACK 








70 


RLC_HO_INFO_DISTRIBUTION_ACK 








71 


RLC FORCE HANDOVER 








72 


RLC FORCE HANDOVER ACK 








73 


RLC AP ABSENCE 


M 





74 


RLC MT INIT REPORT REOUEST 





MO 


75 


RLC MT INIT REPORT REOUEST ACK 





MO 


76 


RLC CHANGE FREOUENCY 


M 


M 


77 


RLC UPLINK PC CALIBRATION 


M 


M 


78 


RLC_MT_ALIVE_REQUEST 


M 


M 


79 


RLC MT ALIVE REQUEST ACK 


M 


M 


80 


RLC_MT_ALIVE 


M 


M 


81 


RLC_MT_ALIVE_ACK 


M 


M 


82 


RLC_MT_ABSENCE 








83 


RLC_MT_ABSENCE_ACK 








84 


RLC SLEEP 





M 


85 


RLC SLEEP ACK 





M 



Table A.6: RLC DUCC SCH PDU messages 



SCH PDU type 


RLC message name 


MT 


AP 


128 


RLC DM CONNECT COMPLETE ACK 








129 


RLC DM MODIFY COMPLETE ACK 









Table A.7: OTHER RLC SCH PDU messages 



SCH PDU type 


RLC message name 


MT 


AP 


255 


RLC NO SUPPORT 


M 


M 
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A.2 Transfer Syntax Tables for LCH ACF messages 
A.2.1 RLC-RBCH-ASSOCIATION encoding 





8|7|6|5|4|3|2| 1 


Octet 4 


NOP-ID Local Part Length {= L) 


Octet 5 


IDENTIFIER-FORMAT | NOP-ID Globally Unique Part Length (= UL) 


Octet 6 


Future use C-U-G 


Octet 7 


H2 Network Operator Identifier string - local part 




H2 Network Operator Identifier string - globally unique part 


Octet 


Future use 


# PROFILE-VID (K) 


Octet 


Profile-ID no.1 


Profile-Version no. 1 


Octet 


Profile-Version no. 1 Profile-ID no. 2 




Profile-Version no. 2 Profile-ID no. 3 




Profile-Version no. 3 


Octet 


Other profile-id and profile version 




Not used 




Octet 51 







Coding rule for profiles: Independent of the number of profiles, the whole of the last octet of the profile field that is not 
filled with profile information is filled with zeroes and the next information field is placed in the next octet. If the 
number of profiles happens to be 4, 5 whole octets are filled with profile information. 

A.2.2 RLC-LINK-CAPABILITY encoding 





8 1 7 1 6 1 5 1 4 


3 1 2 1 1 


Octet 4 


Future use 


# PROFILE-VID (L) 


Octet 5 


Profile-ID no.1 


Profile-Version no. 1 




Profile-Version 
no. 1 


Profile-ID no.2 






Profile-Version no. 2 Profile-ID no.3 




Profile-Version no. 3 




Other profile-id and profile version 


Octet 


Freq-band-IVIT 


RSS value 


Octet 8 -1- (2 X N) 


64QAM 
? 


DM-cap 


Cyclic 
prefix 


FCA? 


FSA? 


Time-gap-ACH-UL 


Octet 


Future use 


ho-cap 


cc-ho-cap 


Future use 


Duty-cycle 


Octet 9 -1- (2 X N) 


ARQ-DELAY-rx 


ARO-DELAY-tx 


Auth/Encr-No-of-Proposals (K) 


Octet 10 + (2 xN) 


Authentication-Proposal-#1 


Encryption-Proposal-#1 


Octet 1 1 + (2 X N) 


Authentication-Proposal-#2 


Encryption-Proposal-#2 




Possibly used for up to 15 proposals (for one CL) 






Octet 


DIL-power- 
control 


TX-ARQ-WIN-SIZE 


RX-ARO-WIN-SIZE 




Not used (size depends on #CL_VID, DIVI-cap, #of proposals) 




Octet 51 
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A.2.3 RLC-LINK-CAPABILITY-ACK encoding 





8 1 7 1 6 1 5 1 4 


3 1 2 1 1 


Octet 4 


Future use 


# PROFILE-VID (L) 


Octet 5 


Profile-ID no.1 


Profile-Version no. 1 




Profile-Version no. 1 Profile-ID no. 2 




Profile-Version no. 2 Profile-ID no.3 




Profile-Version no. 3 




Other profile-id and profile version 


Octet 


Freq-band-sel RSS-value 


Octet 


APT-ADDRESS-LENGTH 


64QAM 


DMCkey 


DM-cap 


Cyclic 
prefix 


Octet 


FCA 


FSA 


Future 
use 


cc-ho-cap 


ARQ-DELAY-rx 


ARQ-DELAY-tx 


Octet 


Authentication-Selected 


Encryption-Selected 


Octet 


DIL-power-control | OUT-ARQ-WIN-SIZE | IN-ARQ-WIN-SIZE 


Octet 


Not used 


Octet... 


Octet 51 



















A.2.4 RLC-KEY-EXCHANGE-MT-1 encoding 





8 


7 


6 1 5 1 4 1 3 


2 


1 


Octet 4 


MT_DH_PUBLIC_VALUE_PART1 




Octet 51 



A.2.5 RLC-KEY-EXCHANGE-l\/IT-2 encoding 





8 


7 


6 1 5 1 4 1 3 


2 


1 


Octet 4 


MT_DH_PUBLIC_VALUE_PART2 




Octet 51 



A.2.6 RLC-KEY-EXCHANGE-AP-1 encoding 





8 


7 


6 1 5 1 4 1 3 


2 


1 


Octet 4 


AP_DH_PUBLIC_VALUE_PART1 




Octet 51 



A.2.7 RLC-KEY-EXCHANGE-AP-2 encoding 





8 


7 


6 1 5 1 4 1 3 


2 


1 


Octet 4 


AP_DH_PUBLIC_VALUE_PART2 




Octet 51 
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A.2.8 RLC-AUTHENTICATION encoding 





8 


7 


6 1 5 1 4 1 3 1 2 1 


1 


Octet 4 


More 


Future use 


Length of MT-AUTH-ID in this PDU (L) 


Octet 5 


Future use | MT-AUTH-ID-TYPE 


Octet 6 


MT-AUTH-ID-CONTENT (L) 






Octet L + 5 


Octet L + 6 


Not used 




Octet 51 



A.2.9 RLC-AUTHENTICATION-MT encoding 





8 


7 


6 


1 5 1 4 1 


3 


2 


1 


Octet 4 


CHALLENGE_TO_IVIT 




Octet 1 9 


Octet 20 


Not used 




Octet 51 



A.2.10 RLC-AUTHENTICATION-AP-1 encoding 





8|7|6|5|4|3|2|1 


Octet 4 


CHALLENGE-TO-AP 




Octet 1 9 


Octet 20 


MT_RESPONSE 

(Possible total length over several PDUs: 16, 64, 96, 128 octets. 

Which one is given by the authentication procedure negotiated during the link 

capability phase.) 














Octet... 


Not used if MT_RESPONSE total length = 1 6 


Octet... 


Octet 51 



A.2.1 1 RLC-AUTHENTICATION-AP-2 encoding 





8|7|6|5|4|3|2|1 


Octet 4 


MT_RESPONSE 

(Possible total length over several PDUs: 64, 96, 128 octets. 

Which one is given by the authentication procedure negotiated during the link 

capability phase.) 














Octet... 


Not used if MT_RESPONSE = 64 


Octet... 


Octet 51 
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A.2.12 RLC-AUTHENTICATION-AP-3 encoding 





8|7|6|5|4|3|2|1 


Octet 4 


MT_RESPONSE 

(Possible total length over several PDUs: 96, 128 octets. 

Which one is given by the authentication procedure negotiated during the link 

capability phase.) 














Octet... 


Not used if MT_RESPONSE = 96 


Octet... 


Octet 51 



A.2.13 RLC-AUTHENTICATION-ACK-1 encoding 





8|7|6|5|4|3|2|1 


Octet 4 


AP_RESPONSE 

(Possible total length over several PDUs: 16, 64, 96, 128 octets. 

Which one is given by the authentication procedure negotiated during the link 

capability phase.) 














Octet... 


Not used (if not by AP_RESPONSE) 


Octet... 


Octet 51 



A.2.14 RLC-AUTHENTICATION-ACK-2 encoding 





8|7|6|5|4|3|2|1 


Octet 4 


AP_RESPONSE 

(Possible total length over several PDUs: 16, 64, 96, 128 octets. 

Which one is given by the authentication procedure negotiated during the link 

capability phase.) 














Octet... 


Not used (if not by AP_RESPONSE) 


Octet... 


Octet 51 



A.2.15 RLC-AUTHENTICATION-ACK-3 encoding 





8|7|6|5|4|3|2|1 


Octet 4 


AP_RESPONSE 

(Possible total length over several PDUs: 16, 64, 96, 128 octets. 

Which one is given by the authentication procedure negotiated during the link 

capability phase.) 














Octet... 


Not used (if not by AP_RESPONSE) 


Octet... 


Octet 51 
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A.2.16 RLC-DM-COMMON-KEY-DISTR encoding (OAP/OMT) 





8 1 7 1 6 1 5 


4 1 3 1 2 1 1 


Octet 4 


Future use 


Encryption algorithm 


Octet 5 


KEY-ID 


Octet 6 


KEY. Length according to encryption algorithm (either 0, 8, or 24 octets). 


Octet ... 


Octet ... 


Octet ... 


Octet ... 


Not used 


Octet ... 


Octet 51 







A.2.17 RLC-DM-COMMON-KEY-DISTR-ACK encoding 
(OAP/OIVIT) 





8 7 6 


1 5 


4 


1 3 1 2 1 


1 


Octet 4 


Future use 


Encryption algorithm 


Octet 5 


MD5-0N-KEY 


Octet ... 


Octet 20 


Octet 21 


Not used 


Octet ... 


Octet 54 



A.2.18 RLC-INFO encoding (OAP/OIVIT) 





8 1 7 


6 


5 1 4 1 3 


2 


1 


Octet 4 


Future use 


Info-type 


INFO-COUNT 


DLC-attr-pr 


CL-attr-pr 


Octet 5 


Future use 


CL Attribute Length (= LI ) (in octets) 


Octet 6 


CL-ID 


Octet 7 


CL attributes (LI) 






Octet 7 + LI 


Future use 




DLC Attribute Length (= L2) (in octets) 






DLC-Attributes 




7 + LI + L2 


Octet... 


Not used 


Octet... 


Octet 51 
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A.2.19 RLC-INFO-ACK encoding (OAP/OMT) 





8 1 7 1 6 


5 1 4 1 3 


2 


1 


Octet 4 


Future use 


INFO-COUNT 


DLC-attr-pr 


CL-attr-pr 


Octet 5 


Future use 


CL Attribute Length (= L1 ) (in octets) 




Octet 6 


CL-ID 


Octet 7 


CL attributes (L1) 






Octet 7 + LI 


Future use 


DLC Attribute Length (= L2) (in octets) 






DLC-Attributes 




7 + LI + L2 


Octet... 


Not used 


Octet... 


Octet 51 



A.2.20 RLC-UNICAST-KEY-REFRESH encoding (OAP) 





8 


7 


6 


5 1 4 


3 


2 


1 


Octet 4 


NONCE 


Octet ... 


Octet ... 


Octet 1 9 


Octet 20 


Not used 


Octet ... 


Octet 51 



A.2.21 RLC-UNICAST-KEY-REFRESH-ACK encoding (OAP) 





8 


7 


6 


1 5 1 4 1 


3 


2 


1 


Octet 4 


MD5-0N-N0NCE 


Octet ... 


Octet ... 


Octet 1 9 


Octet 20 


Not used 


Octet... 


Octet 51 



A.2.22 RLC-COIVIIVION-KEY-REFRESH encoding (OAP) 





8 1 7 1 6 1 5 


4 1 3 1 2 


1 


Octet 4 


Future use 


Encr Info 


Octet 5 


KEY- ID 


Octet 6 


KEY. Length according to encryption algorithm. 


Octet ... 


Octet ... 


Octet ... 


Octet ... 


Not used 


Octet ... 


Octet 51 
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A.2.23 RLC-COMMON-KEY-REFRESH-ACK encoding (OAP) 





8 


7 1 6 


1 5 


4 1 


3 1 2 


1 


Octet 4 


Future use 


Encr Info 


Octet 5 


MD5-0N-KEY 


Octet 6 


Octet ... 


Octet ... 


Octet 20 


Octet 21 


Not used 


Octet ... 


Octet 51 



A.2.24 RLC-GROUP-JOIN encoding (OAP/OIVIT) 





8 7 6 5 


4 3 2 1 


Octet 4 


Length of each CL attribute in 
octets (L) 


Number of CL attributes (n) 


Octet 5 


CL-ID 


Octet 6 


CL-attributes 
(Higher layer group addresses) 


Octet ... 


Octet (L X n + 5) 


Octet (L X n + 6) 


Future use 


No. of encryption proposals (k) 


Octet (L X n + 7) 


Encryption proposal no. 1 


Encryption proposal no. 2 














Octet (L X n + 6 + k/2) 


Encryption proposal no. k-1 


Encryption proposal no. k 


Octet ... 


Not used 


Octet ... 


Octet 51 







A.2.25 RLC-GROUP-JOIN-ACK encoding (OAP/OIVIT) 





8 


7 1 6 1 5 


4 1 3 1 2 1 1 


Octet 4 


more-joins 


Future use 


Number of MAC-ID:s And CL-data (N) 


Octet 5 




Length-of-CL-data in octets (L) 


Octet 6 


MAC-ID no. 1 


Octet 7 


CL-data no.1 


Octet 7 + L 


Octet 


MAC-ID no. N 




CL-data no.N 


Octet N X (L + 1 ) + 5 


Octet N X (L + 1 ) + 6 


Future use Encryption algorithm selected 


Octet N X (L + 1 ) + 7 


Key-ID 




Common Key. Length given by Encryption algorithm selected (K). 
K is octets for no-encr, 8 octets for DES, and 24 octets for tripleDES. 




Octet Nx(L + 1) + 7 + K 




Not used 


Octet ... 


Octet 51 
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A.2.26 RLC-GROUP-JOIN-NACK encoding (OAP/OMT) 





8 1 7 1 6 1 5 


4 1 3 1 2 1 1 


Octet 4 


Length of each CL attribute{L) 


Number of CL attributes (N) 


Octet 5 


CL-ID 




CL Attributes 
(Higher layer group addresses) 






Octet 5 + 


LxN 




Not used 




Octet 51 







A.2.27 RLC-GROUP-LEAVE encoding (OAP/OIVIT) 





8 1 7 1 6 1 5 


4 1 3 1 2 1 1 


Octet 4 


Lenqth of each CL attribute (L) 


Number of CL attributes (N) 


Octet 5 


CL-ID 




CL Attributes 
(Higher layer group addresses) 






Octet 5 + 


LxN 




Not used 




Octet 51 







A.2.28 RLC-GROUP-LEAVE-ACK encoding (OAP/OIVIT) 





8 1 7 1 6 1 5 


4 1 3 1 2 1 1 


Octet 4 


Lenqth of each CL attribute (L) 


Number of CL attributes (N) 


Octet 5 


CL-ID 




CL Attributes 
(Higher layer group addresses) 






Octet 5 + L X N 




Not used 




Octet 51 







A.2.29 RLC-CL-BROADCAST-JOIN encoding (OAP/OMT) 





8 1 7 1 6 1 5 


4 1 3 1 2 1 1 


Octet 4 


Length of each CL attribute (L) 


Number of CL attributes (N) 


Octet 5 


CL-ID 


Octet 6 


CL attributes 
(Higher layer broadcast addresses) 


Octet 7 


Octet 8 


Octet L X N + 5) 


Octet (L X n -H 6) 


Future use 


No. of encryption proposals (k) 


Octet (L X n -H 7) 


Encryption proposal no. 1 


Encryption proposal no. 2 


Octet ... 






Oct (L X n + 6 + VJ2) 


Encryption proposal no. (k-1) 


Encryption proposal no. k 




Not used 




Octet 51 
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A.2.30 RLC-CL-BROADCAST-JOIN-ACK encoding (OAP/OMT) 





8 


7 


6 1 5 


4 1 3 1 2 1 1 


Octet 4 


more-joins 


rep/unac 
k 


Window size 


No. of MAC-ID:s and CL-data (N) 


Octet 5 




Length of CL-data in octets (L) 


Octet 6 


MAC-ID no. 1 




CL-data no. 1 (L) 






MAC-ID no. 2 




CL-data no.2 (L) 






MAC-ID no. N 




CL-data no. N (L) 


Octet 5 + (N X L) 




Future use Encryption algorithm selected 


Octet 5 + (N X L) + 2 


Key-ID 




Key. Length given by Encryption algorithm selected (K) 
K is octets for no-encr, 8 octets for DES and 24 octets for tripleDES 






Octet 5 + (NxL) + 2 + K 




Not used 




Octet 51 











A.2.31 RLC-CL-BROADCAST-LEAVE encoding (OAP/OIVIT) 





8 1 7 1 6 1 5 


4 1 3 1 2 1 1 


Octet 4 


Length of each CL attribute (L) 


Number of CL attributes (N) 


Octet 5 


CL-ID 


Octet 6 


CL attributes 
(Higher layer or peer layer broadcast addresses) 




Octet (L x n -H 


5) 




Not used 




Octet 51 







A.2.32 RLC-CL-BROADCAST-LEAVE-ACK encoding (OAP/OIVIT) 





8 1 7 1 6 1 5 


4 1 3 1 2 1 1 


Octet 4 


Length of each CL attribute (L) 


Number of CL attributes (N) 


Octet 5 


CL-ID 


Octet 6 


CL attributes 
(Higher layer or peer layer broadcast addresses) 




Octet L X N + 5 




Not used 




Octet 51 




i 
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A.3 Transfer Syntax Tables for LCH RRC messages 

A.3.1 RLC-RADIO-HANDOVER-COMPLETE encoding 
(OAP/OMT) 





8 1 7 1 6 1 5 


4 1 3 1 2 1 1 


Octet 4 


Future use 


MAC-ID-GLD 


Octet 5 


MAC-ID-OLD 


AP-ID-OLD 


Octet 6 


AP-ID-OLD 1 NET-ID-OLD 


Octet 7 


NET-ID-OLD 


Octet 8 


MAC-ID-NEW 


Octet 9 


CL-ID 


Octet 10 


EXT-IND 1 CL-CONN-ATTR-LENGTH (L) | # of DUC:s 


Octet 1 1 


#ofDUC:s(N) 


Future use 


Octet! 2 


DUC1 -DIRECTION 


DLCC-ID 




CL-CONN-ATTR 


Octet (12 + L) 


Octet Y 


DUC1 -FW-TYPE-OF-ALLOCATION 


Future 
use 


CYCLIC-PREFIX 


FEC-USED 


EC-MODE 


Octet ... 


DUC1 -FW-NUM-OF-RETRANSMISSIONS 


Future use 


DUC1-FW-ARG-WIN-SIZE 1 




FEC-FW 


Future Use 


Octet ... 


PER-#-MAC-FRAME (SCH) 


PER-#-MAC-FRAME (LCH) 


Octet ... 


REG 
SCH 


PHY-MODE-SCH 


PHY-MODE-LCH 


Octet ... 


REQUESTED-NUM-OF-LCH 


Octet ... 


MINUMUM-NUM-OF-LCH 


Octet ... 


Future use PHY-MODE-LCH 


Octet ... 


NB-OF-LCH 


Octet ... 


MIN-NB-OF-LCH 


Octet ... 


start-pointer 


Octet ... 


start-pointer Future use 


Octet ... 


repetition-counter 


Octet ... 


repetition-counter frame-count 


Octet X 


DUC1 -FW-TYPE-OF-ALLOCATION 


Future 
use 


CYCLIC-PREFIX 


FEC-USED 


EC-MODE 


Octet ... 


DUC1 -FW-NUM-OF-RETRANSMISSIONS 


Future use 


DUC1-FW-ARG-WIN-SIZE | 




FEC-FW 


Future Use 


Octet ... 


PER-#-MAC-FRAME (SCH) 


PER-#-MAC-FRAME (LCH) 


Octet ... 


REG 
SCH 


PHY-MODE-SCH 


PHY-MODE-LCH 


Octet ... 


REGUESTED-NUM-OF-LCH 


Octet... 


MINUMUM-NUM-OF-LCH 


Octet ... 


Future use | PHY-MODE-LCH 


Octet ... 


NB-OF-LCH 


Octet ... 


MIN-NB-OF-LCH 


Octet ... 


start-pointer 


Octet ... 


start-pointer Future use 


Octet ... 


repetition-counter 


Octet ... 


repetition-counter frame-count 


Octet ... 


Not used 


Octet ... 


Octet 51 

















Total length = 12 -i- L -i- 14 x N if asymmetric duplex with fixed capacity agreement and with FEC. 

Total length = 12-i-L-i-6xNif asymmetric duplex with basic allocation and with FEC. 

Total length = 12-i-L-i-7xNif symmetric duplex with fixed capacity agreement and with FEC. 

Total length =12-i-L-i-3xNif symmetric duplex with basic allocation and with FEC. 

Total length =12-i-L-i-3xNif simplex with basic allocation and with FEC. 
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Total length = 12 + L + 7xNif simplex with fixed capacity agreement and with FEC. 

Total length = 12 + L+ 12xNif asymmetric duplex with fixed capacity agreement and without FEC. 

Total length = 12 + L + 4xNif asymmetric duplex with basic allocation and without FEC. 

Total length = 12 + L + 6xNif symmetric duplex with fixed capacity agreement and without FEC. 

Total length = 12 + L + 2xNif symmetric duplex with basic allocation and without FEC. 

Total length = 12 + L + 2xNif simplex with basic allocation and without FEC. 

Total length = 12 + L + 6xNif simplex with fixed capacity agreement and without FEC. 

Fixed Slot Allocation (FSA) may be used in any EC mode and with or without FEC. When using unacknowledged 
mode, a MT does not have to decode the FCCH once the connection is set up. When using acknowledged mode, a MT 
shall decode the FCCH, because SCHs for acknowledgements and discards are granted in basic allocation mode. Only 
LCHs can be allocated with FSA. In the following the total length of the PDU is given for the unacknowledged mode: 

Total length = 12 + L+ ISxNif asymmetric duplex with FSA and with FEC. 

Total length = 12 + L + 9xNif symmetric duplex with FSA and with FEC. 

Total length =12 + L + 9xNif simplex with FSA and with FEC. 

Total length = 12 + L+ 16xNif asymmetric duplex with FSA and without FEC. 

Total length = 12 + L + 8xNif symmetric duplex with FSA and without FEC. 

Total length =12 + L + 8xNif simplex with FSA and without FEC. 

A.3.2 RLC-HANDOVER-ASSOCIATION encoding (OAP/OMT) 





8 1 7 1 6 1 5 1 4 1 


3 1 2 1 1 


Octet 4 


MAC-ID-OLD 


Octet 5 


Future use 


AP-ID-OLD 


Octet 6 


AP-ID-OLD 


1 NET-ID-OLD 


Octet 7 


NET-ID-OLD 


Octet 8 


MAC-ID-NEW 


Octet... 


Future use 


Octet 51 
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A.3.3 RLC-HANDOVER-LINK-CAPABILITY-ACK encoding 
(OAP/OMT) 





8 1 7 1 6 1 5 1 4 


3 1 2 1 1 


Octet 4 


Future use 


# PROFILE-VID (L) 


Octet 5 


Profile-ID no.1 


Profile-Version no. 1 


Octet ... 


Profile-Version no. 1 Profile-ID no. 2 


Octet ... 


Profile-Version no. 2 | Profile-ID no. 3 


Octet ... 


Profile-Version no. 3 


Octet ... 


Other profile-id and profile version 


Octet ... 


Freq-band-sel RSS-value 


Octet ... 


APT-ADDRESS-LENGTH 


64QA 
M? 


APDMcap 


DMCkey 


Cyclic prefix 


Octet ... 


FCA? 1 FSA? 1 Future use | cc-ho-cap 


ARQ-DELAY-rx 


ARQ-DELAY-tx 


Octet ... 


Authentication-Selected 


Encryption-Selected 


Octet ... 


Encrypt? 


Authent? 


NWTkn? 


DUCSu? 


Future use 


connections 


Info-transfer 


Octet ... 


DIL-power-control 


TX-ARQ-WIN-SIZE 


RX-ARQ-WIN-SIZE 


Octet ... 


Not used 


Octet ... 


Octet 51 



















A.3.4 RLC-NW-SIGNALLING-HANDOVER encoding (OAP/OIVIT) 





8 


7 


1 6 1 5 1 4 1 3 1 


2 


1 


Octet 4 


MD5-0N-MT-T0KEN-AUTH-ENCR 






Octet 1 9 


Octet 20 


Not used 


Octet ... 


Octet 51 



A.3.5 RLC-NW-SIGNALLING-HANDOVER-ACK encoding 
(OAP/OIVIT) 





8|7|6|5|4|3|2|1 


Octet 4 


AP-token 




Octet 1 9 


Octet 20 




Auth/Encr-No-of-Proposals (K) 


Octet 21 


Authentication-Proposal-#1 


Encryption-Proposal-#1 








Octet 20 -^ K 


Authentication-Proposal-#K 


Encryption-Proposal-#K 


Octet 21 + K 


Authentication-Proposal-Selected 


Encryption-Proposal-Selected 


Octet ... 


Future use 


Octet ... 


Octet 51 
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A.3.6 RLC-NETWORK-HANDOVER-COMPLETE encoding 
(OAP/OMT) 





8|7|6|5|4|3|2|1 


Octet 4 


CL-ID 


Octet 5 


EXT-IND 1 CL-CONN-ATTR-LENGTH (L) | # of DUC:s 


Octet 6 


#ofDUC:s(N) 


Future use 


Octet 7 


DUC1-DIRECTI0N 


DLCC-ID 




CL-CONN-ATTR 


Octet (7 + L) 


Octet Y 


DUC1 -FW-TYPE-OF-ALLOCATION 


Future 
use 


Cyclic-pref 


FEC-USED 


EC-MODE 


Octet ... 


DUC1 -FW-NUM-OF-RETRANSMISSIONS 


Future 
use 


DUC1 -FW-ARQ-WIN-SIZE 




FEC-FW 


Future Use 


Octet ... 


PER-#-MAC-FRAME (SCH) 


PER-#-MAC-FRAME (LCH) 


Octet ... 


REQSCHi PHY-MODE-SCH 


PHY-MODE-LCH 


Octet ... 


REQUESTED-NUM-OF-LCH 


Octet ... 


MINUMUM-NUM-OF-LCH 


Octet ... 


Future use PHY-MODE-LCH 


Octet ... 


NB-OF-LCH 


Octet ... 


MIN-NB-OF-LCH 


Octet ... 


start-pointer 


Octet ... 


start-pointer Future use 


Octet ... 


repetition-counter 


Octet ... 


repetition-counter frame-count 


Octet X 


DUC1 -BW-TYPE-OF-ALLOCATION 


Future 
use 


Cyclic-pref 


FEC-USED 


EC-MODE 


Octet ... 


DUC1 -BW-NUM-OF-RETRANSMISSIONS 


Future 
use 


DUC1-BW-ARQ-WIN-SIZE 




FEC-BW 


Future Use 


Octet ... 


PER-#-IVIAC-FRAME (SCH) 


PER-#-MAC-FRAME (LCH) 


Octet ... 


REQSCHi PHY-MODE-SCH 


PHY-MODE-LCH 


Octet ... 


REQUESTED-NUM-OF-LCH 


Octet... 


MINUMUM-NUM-OF-LCH 


Octet ... 


Future use | PHY-IVIODE-LCH 


Octet ... 


NB-OF-LCH 


Octet ... 


MIN-NB-OF-LCH 


Octet ... 


start-pointer 


Octet ... 


start-pointer Future use 


Octet ... 


repetition-counter 


Octet ... 


repetition-counter frame-count 


Octet ... 


Not used 


Octet ... 


Octet 51 















Total length = 7h-Lh- 14xNif asymmetric duplex with fixed capacity agreement and with FEC. 

Total length = 7H-LH-6xNif asymmetric duplex with basic allocation and with FEC. 

Total length = 7H-LH-7xNif symmetric duplex with fixed capacity agreement and with FEC. 

Total length = 7H-LH-3xNif symmetric duplex with basic allocation and with FEC. 

Total length = 7H-LH-3xNif simplex with basic allocation and with FEC. 

Total length = 7H-LH-7xNif simplex with fixed capacity agreement and with FEC. 

Total length = 7h-Lh- 12xNif asymmetric duplex with fixed capacity agreement and without FEC. 

Total length = 7H-LH-4xNif asymmetric duplex with basic allocation and without FEC. 

Total length = 7H-LH-6xNif symmetric duplex with fixed capacity agreement and without FEC. 
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Total length = 7 + L + 2xNif symmetric duplex with basic allocation and without FEC. 

Total length = 7 + L + 2xNif simplex with basic allocation and without FEC. 

Total length = 7 + L + 6xNif simplex with fixed capacity agreement and without FEC. 

Fixed Slot Allocation (FS A) may be used in any EC mode and with or without FEC. When using unacknowledged 
mode, a MT does not have to decode the FCCH once the connection is set up. When using acknowledged mode, a MT 
shall decode the FCCH, because SCHs for acknowledgements and discards are granted in basic allocation mode. Only 
LCHs can be allocated with FS A. In the following the total length of the PDU is given for the unacknowledged mode: 

Total length = 7 + L+ ISxNif asymmetric duplex with FSA and with FEC. 

Total length = 7 + L + 9xNif symmetric duplex with FSA and with FEC. 

Total length = 7 + L + 9xNif simplex with FSA and with FEC. 

Total length = 7 + L+ 16xNif asymmetric duplex with FSA and without FEC. 

Total length = 7 + L + 8xNif symmetric duplex with FSA and without FEC. 

Total length = 7 + L + 8xNif simplex with FSA and without FEC. 

A.3.7 RLC-HO-INFO-DISTRIBUTION encoding (OAP/OMT) 





8 


7 


6 


5 1 4 


3 


2 


1 


Octet 4 


TOKEN 


Octet ... 


Octet ... 


Octet 1 9 


Octet 20 


Not used 


Octet ... 


Octet 51 



A.3.8 RLC-DFS-MEASUREMENT-COMPLETE-REQUEST 
encoding 





8 1 7 1 6 


5 1 4 1 3 1 2 1 1 


Octet 4 


FREQUENCY-INDEX 


Octet 5 


Future use 


UOA 


START-OF-MEASUREMENT 


Octet 6 


Future use 


MEASUREMENT-WINDOW 


Octet 7 


Future use 


1 MAXIMUM-AGE-OF-MEASUREMENT 


Octet 8 


MAXIMUM-AGE-OF-MEASUREMENT 


Octet 9 


Future use 


RSS-INDEX 1 


Octet 1 


RSS-INDEX2 


RSS-INDEX3 


Octet 1 1 


RSS-INDEX4 


RSS-INDEX 5 


Octet... 


Not used 


Octet... 


Octet 51 
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A.3.9 RLC-DFS-MEASUREMENT-PERCENTILES-REQUEST 
encoding 





8 1 7 1 6 


1 5 1 4 1 3 1 2 1 1 


Octet 4 


FREQUENCY-INDEX 


Octet 5 


Future use 


1 UOA 1 START-OF-MEASUREMENT 


Octet 6 


Future use 


MEASUREMENT-WINDOW 


Octet 7 


Future use 


Octet 8 


Octet 9 


Future use 


RSS-INDEX 1 


Octet 10 


RSS-INDEX2 


RSS-INDEX3 


Octet 1 1 


RSS-INDEX4 


RSS-INDEX 5 


Octet ... 


Not used 


Octet ... 


Octet 51 



A.3.10 RLC-DFS-MEASUREMENT-SHORT-REQUEST encoding 





8 7 6 5 4 3 2 1 


Octet 4 


FREQUENCY-INDEX 
FREQUENCY-INDEX 


Octet 5 


Future use 


UOA 


START-OF-MEASUREMENT 


Octet 6 


Future use | MEASUREMENT-WINDOW 


Octet 7 


Future use | MAXIMUM-AGE-OF-MEASUREMENT 


Octet 8 


MAXIMUM-AGE-OF-MEASUREMENT 


Octet... 


Not used 


Octet... 


Octet 51 









A.3.11 RLC-DFS-REPORT-COIVIPLETE encoding 





8 |7|6|5|4|3|2|1 


Octet 4 


FREQUENCY-INDEX 


Octet 5 


Future use | OAU | AGE-OF-MEASUREMENT 


Octet 6 


AGE-OF-MEASUREMENT 


Octet 7 


Future use 


LAST-OWN-BCH-RX-LEVEL 


Octet 8 


Future use 


NUMBER-OF-SAMPLES 


Octet 9 


NUMBER-OF-SAMPLES 


Octet 1 


BCH- 
FOUND 


Future use 


TRAFFIC-LOAD 


AP-ID 


Octet 1 1 


AP-ID 


Octet 1 2 


Future use | TX-LEVEL | NET-ID 


Octet 13 


NET-ID 


Octet 14 


Future use | BCH-RX-LEVEL 


Octet 1 5 


Future use 


RSS-INDEX 1 


Octet 1 6 


RSS-INDEX 2 


RSS-INDEX 3 


Octet 1 7 


RSS-INDEX 4 


RSS-INDEX 5 


Octet 1 8 


Future use 


RSS-STATISTICS 1 


Octet 1 9 


Future use 


RSS-STATISTICS 2 


Octet 20 


Future use 


RSS-STATISTICS 3 


Octet 21 


Future use 


RSS-STATISTICS 4 


Octet 22 


Future use 


RSS-STATISTICS 5 


Octet 23 


Not used 


Octet... 


Octet 51 
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A.3.12 RLC-DFS-REPORT-PERCENTILES encoding 





8 1 7 1 6 


1 5 1 4 1 3 1 2 1 


1 


Octet 4 


FREQUENCY-INDEX 


Octet 5 


Future use 


OAU Future use 




Octet 6 


Future use 


Octet 7 


Future use 


LAST-OWN-BCH-RX-LEVEL 


Octet 8 


Future use 


NUMBER-OF-SAMPLES 


Octet 9 


NUMBER-OF-SAMPLES 


Octet 1 


Future use 


Octet 1 1 


Octet 1 2 


Octet 1 3 


Octet 14 


Octet 1 5 


Future use 


RSS-INDEX 1 


Octet 1 6 


RSS-INDEX2 


RSS-INDEX3 


Octet 1 7 


RSS-INDEX4 


RSS-INDEX 5 


Octet 1 8 


Future use 


RSS-STATISTICS 1 


Octet 1 9 


Future use 


RSS-STATISTICS 2 


Octet 20 


Future use 


RSS-STATISTICS 3 


Octet 21 


Future use 


RSS-STATISTICS 4 


Octet 22 


Future use 


RSS-STATISTICS 5 


Octet 23 


Not used 


Octet... 


Octet 51 



A.3.13 RLC-DFS-REPORT-SHORT encoding 





8 |7|6|5|4|3|2|1 


Octet 4 


FREQUENCY-INDEX 


Octet 5 


Future use | OAU | AGE-OF-MEASUREMENT 


Octet 6 


AGE-QF-MEASUREMENT 


Octet 7 


Future use LAST-OWN-BCH-RX-LEVEL 


Octet 8 


Future use 


Octet 9 


Octet 1 


BCH- 
FOUND 


Future use 


TRAFFIC-LOAD 


AP-ID 


Octet 1 1 


AP-ID 


Octet 1 2 


Future use | TX-LEVEL | NET-ID 


Octet 13 


NET-ID 


Octet 14 


Future use | BCH-RX-LEVEL 


Octet 1 5 


Not used 


Octet... 


Octet 51 
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A.4 Transfer Syntax Tables for LCH DUCC messages 



A.4.1 RLC-SETUP encoding 





8|7|6|5| 4 |3|2|1 


Octet 4 


CL-ID 


Octet 5 


duc-ext 1 CL-CONN-ATTR-LENGTH(L) | # of DUC:s 


Octet 6 


#ofDUC:s(N) 


Future use 


Octet 7 


DUC1-DIRECTI0N 


DLCC-ID 




CL-CONN-ATTR 


Octet 7 + L 


Octet Y 


DUC1 -FW-TYPE-OF-ALLOCATION 


Future 
use 


CYCLIC-PREFIX 


FEC- 
USED 


EC-MODE 


Octet ... 


DUC1-FW-NUM-0F- 
RETRANSMISSIONS 


Future use 


DUC1-FW-ARQ-WIN- 
SIZE 




FEC-FW 


Future Use 


Octet ... 


PER-#-MAC-FRAME(SCH) 


PER-#-MAC-FRAME(LCH) 


Octet ... 


REO 
SCH 


PHY-MODE-SCH 


PHY-MODE-LCH 


Octet ... 


REQUESTED-NUM-OF-LCH 


Octet ... 


MINUMUM-NUM-OF-LCH 


Octet ... 


Future use | PHY-MODE-LCH 


Octet ... 


NB-OF-LCH 


Octet ... 


MIN-NB-OF-LCH 


Octet ... 


start-pointer 


Octet ... 


start-pointer Future use 


Octet ... 


repetition-counter 


Octet ... 


repetition-counter 


frame-count 


Octet X 


DUC1 -BW-TYPE-OF-ALLOCATION 


Future 
use 


CYCLIC-PREFIX 


FEC- 
USED 


EC-MODE 


Octet ... 


DUC1-BW-NUM-0F- 
RETRANSIVIISSIONS 


Future use 


DUC1-BW-ARQ-WIN- 
SIZE 




FEC-BW 


Future Use 


Octet ... 


PER-#-MAC-FRAME(SCH) 


PER-#-MAC-FRAME(LCH) 


Octet ... 


REO 
SCH 


PHY-MODE-SCH 


PHY-MODE-LCH 


Octet ... 


REQUESTED-NUM-OF-LCH 


Octet ... 


MINUMUM-NUM-OF-LCH 


Octet ... 


Future use | PHY-MODE-LCH 


Octet ... 


NB-OF-LCH 


Octet ... 


MIN-NB-OF-LCH 


Octet ... 


start-pointer 


Octet ... 


start-pointer Future use 


Octet ... 


repetition-counter 


Octet ... 


repetition-counter frame-count 


Octet ... 


Not used 


Octet ... 


Octet 51 

















Total length = 7h-Lh- 14xNif asymmetric duplex with fixed capacity agreement and with FEC. 

Total length = 7H-LH-6xNif asymmetric duplex with basic allocation and with FEC. 

Total length = 7H-LH-7xNif symmetric duplex with fixed capacity agreement and with FEC. 

Total length = 7H-LH-3xNif symmetric duplex with basic allocation and with FEC. 

Total length = 7H-LH-3xNif simplex with basic allocation and with FEC. 

Total length = 7H-LH-7xNif simplex with fixed capacity agreement and with FEC. 

Total length = 7h-Lh- 12xNif asymmetric duplex with fixed capacity agreement and without FEC. 
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Total length = 7 + L + 4xNif asymmetric duplex with basic allocation and without FEC. 

Total length = 7 + L + 6xNif symmetric duplex with fixed capacity agreement and without FEC. 

Total length = 7 + L + 2xNif symmetric duplex with basic allocation and without FEC. 

Total length = 7 + L + 2xNif simplex with basic allocation and without FEC. 

Total length = 7 + L + 6xNif simplex with fixed capacity agreement and without FEC. 

Fixed Slot Allocation (FSA) may be used in any EC mode and with or without FEC. When using unacknowledged 
mode, a MX does not have to decode the FCCH once the connection is set up. When using acknowledged mode, a MT 
shall decode the FCCH, because SCHs for acknowledgements and discards are granted in basic allocation mode. Only 
LCHs can be allocated with FSA. In the following the total length of the PDU is given for the unacknowledged mode: 

Total length = 7 + L+ ISxNif asymmetric duplex with FSA and with FEC. 

Total length = 7 + L + 9xNif symmetric duplex with FSA and with FEC. 

Total length = 7 + L + 9xNif simplex with FSA and with FEC. 

Total length = 7 + L+ 16xNif asymmetric duplex with FSA and without FEC. 

Total length = 7 + L + 8xNif symmetric duplex with FSA and without FEC. 

Total length = 7 + L + 8xNif simplex with FSA and without FEC. 
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A.4.2 RLC-CONNECT encoding 





8|7|6|5| 4 |3|2|1 


Octet 4 


CL-ID 


Octet 5 


Future 
use 


CL-CONN-ATTR-LENGTH (L) 


# of DUC:s 


Octet 6 


#of DUC:s(N) 


Future use 


Octet 7 


DUC1 -DIRECTION 


DLCC-ID 




CL-CONN-ATTR 


Octet 7 + L 




Octet Y 


DUC1-FW-TYPE-0F-ALL0CATI0N 


Future 
use 


CYCLIC-PREFIX 


REC- 
USED 


EC-MODE 


Octet ... 


DUC1-FW-NUM-0F- 
RETRANSMISSIONS 


Future use 


DUC1-FW-ARQ-WIN-SIZE 




FEC-FW 


Future Use 


Octet .. 




PER-#-MAC-FRAME (SCH) 


PER-#-MAC-FRAME (LCH) 


Octet .. 




REQSCH 1 PHY-MODE-SCH 


PHY-MODE-LCH 


Octet .. 




REQUESTED-NUM-OF-LCH 


Octet .. 




MINUMUM-NUM-OF-LCH 


Octet .. 




Future use | PHY-MODE-LCH 


Octet .. 




NB-OF-LCH 


Octet .. 




MIN-NB-OF-LCH 


Octet .. 




start-pointer 


Octet .. 




start-pointer Future use 


Octet .. 




repetition-counter 


Octet .. 




repetition-counter 


frame-count 


Octet X 


DUC1 -BW-TYPE-OF-ALLOCATION 


Future 
use 


CYCLIC-PREFIX 


FEC- 
USED 


EC-MODE 


Octet ... 


DUC1-BW-NUM-0F- 
RETRANSIVIISSIONS 


Future use 


DUC1-BW-ARQ-WIN-SIZE 




FEC-BW 


Future Use 


Octet .. 




PER-#-MAC-FRAME (SCH) 


PER-#-MAC-FRAME (LCH) 


Octet .. 




REQSCH PHY-MODE-SCH 


PHY-MODE-LCH 


Octet .. 




REQUESTED-NUM-OF-LCH 


Octet .. 




MINUMUM-NUM-OF-LCH 


Octet .. 




Future use | PHY-MODE-LCH 


Octet .. 




NB-OF-LCH 


Octet .. 




MIN-NB-OF-LCH 


Octet .. 




start-pointer 


Octet .. 




start-pointer Future use 


Octet .. 




repetition-counter 


Octet .. 




repetition-counter frame-count 


Octet .. 




Not used 
Not used 


Octet .. 




Octet 51 

















Total length = 7h-Lh- 14xNif asymmetric duplex with fixed capacity agreement and with FEC. 

Total length = 7H-LH-6xNif asymmetric duplex with basic allocation and with FEC. 

Total length = 7H-LH-7xNif symmetric duplex with fixed capacity agreement and with FEC. 

Total length = 7H-LH-3xNif symmetric duplex with basic allocation and with FEC. 

Total length = 7H-LH-3xNif simplex with basic allocation and with FEC. 

Total length = 7H-LH-7xNif simplex with fixed capacity agreement and with FEC. 

Total length = 7h-Lh- 12xNif asymmetric duplex with fixed capacity agreement and without FEC. 

Total length = 7H-LH-4xNif asymmetric duplex with basic allocation and without FEC. 

Total length = 7H-LH-6xNif symmetric duplex with fixed capacity agreement and without FEC. 

Total length = 7H-LH-2xNif symmetric duplex with basic allocation and without FEC. 
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Total length = 7 + L + 2xNif simplex with basic allocation and without FEC. 

Total length = 7 + L + 6xNif simplex with fixed capacity agreement and without FEC. 

Fixed Slot Allocation (FSA) may be used in any EC mode and with or without FEC. When using unacknowledged 
mode, a MT does not have to decode the FCCH once the connection is set up. When using acknowledged mode, a MT 
shall decode the FCCH, because SCHs for acknowledgements and discards are granted in basic allocation mode. Only 
LCHs can be allocated with FSA. In the following the total length of the PDU is given for the unacknowledged mode: 

Total length = 7 + L+ ISxNif asymmetric duplex with FSA and with FEC. 

Total length = 7 + L + 9xNif symmetric duplex with FSA and with FEC. 

Total length = 7 + L + 9xNif simplex with FSA and with FEC. 

Total length = 7 + L+ 16xNif asymmetric duplex with FSA and without FEC. 

Total length = 7 + L + 8xNif symmetric duplex with FSA and without FEC. 

Total length = 7 + L + 8xNif simplex with FSA and without FEC. 



A.4.3 RLC-CONNECT-ACK encoding 





8 |7|6|5| 4 |3| 2 |1 


Octet 4 


CL-ID (filled with same contents as setup message) 


Octet 5 


Future 
use 


CL-CONN-ATTR-LENGTH (L) 


# of DLCC+CL-CON- 
ATT 


Octet 6 


# of DLCC+CL- 
CON-ATT(N) 


Future use 


Octet ... 


Future use 


DLCC-ID-1 


Octet ... 


CL-CONN-ATTR-1 


Octet ... 


Octet ... 


Future use | DLCC-ID-2 


Octet ... 


CL-CONN-ATTR-2 


Octet... 6+(L+ 1)xN 


Octet ... 


Not used 


Octet ... 


Octet 51 











A.4.4 RLC-RELEASE encoding 





8 1 7 1 6 


5 


4 1 3 1 2 1 


1 


Octet 4 


Future use 


RELEASE-CAUSE 


Octet 5 


Future use 


# of DLCC-ID (N) 


Octet ... 


Future use 


DLCC-1D#1 




Future use 


DLCC-ID... 


Octet 5 + N 


Future use 


DLCC-ID#N 


Octet ... 


Not used 


Octet ... 


Octet 51 
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A.4.5 RLC-RELEASE-ACK encoding 





8 1 7 1 6 1 5 


4 1 3 1 2 1 1 


Octet 4 


Future use 


# of DLCC-ID (N) 


Octet ... 


Future use 


DLCC-ID#1 




Future use 


DLCC-ID... 


Octet 4 -^ N 


Future use 


DLCC-ID#N 


Octet ... 


Not used 


Octet ... 


Octet 51 









A.4.6 RLC-MODIFY-REQUEST encoding (OAP/OIVIT) 





8 


7 1 6 1 5 1 4 1 3 


2 1 1 


Octet 4 


duc-ext-ind 


CL-CONN-ATTR-LENGTH (L) 


#ofDUC:s 


Octet 5 


#of DUC:s(N) 


Future use 


Octet 6 


DUC1 -DIRECTION 


DLCC-ID 




CL-CONN-ATTR 


Octet 6 -1- L 




Octet Y 


DUC1-FW-TYPE-0F- 
ALLOCATION 


Future 
use 


CYCLIC-PREFIX 


FEC- 
USED 


EC-MODE 


Octet ... 


DUC1-FW-NUM-0F- 
RETRANSMISSIONS 


Future use 


DUC1-FW-ARQ-WIN- 
SIZE 




FEC-FW 


Future Use 


Octet ... 


PER-#-MAC-FRAME (SCH) 


PER-#-MAC-FRAME (LCH) 


Octet ... 


REO 
SCH 


PHY-MODE-SCH 


PHY-MODE-LCH 


Octet ... 


REQUESTED-NUM-OF-LCH 


Octet ... 


MINUMUM-NUM-OF-LCH 


Octet ... 


Future use PHY-MODE-LCH 


Octet ... 


NB-OF-LCH 


Octet ... 


MIN-NB-OF-LCH 


Octet ... 


start-pointer 


Octet ... 


start-pointer Future use 


Octet ... 


repetition-counter 


Octet ... 


repetition-counter frame-count 


Octet X 


DUC1-BW-TYPE-0F- 
ALLOCATION 


Future 
use 


CYCLIC-PREFIX 


FEC- 
USED 


EC-MODE 


Octet ... 


DUC1-BW-NUM-0F- 
RETRANSMISSIONS 


Future use 


DUC1-BW-ARQ-WIN- 
SIZE 




FEC-BW 


Future Use 


Octet ... 


PER-#-MAC-FRAME (SCH) 


PER-#-MAC-FRAME (LCH) 


Octet ... 


REO 
SCH 


PHY-MODE-SCH 


PHY-MODE-LCH 


Octet ... 


REQUESTED-NUM-OF-LCH 


Octet ... 


MINUMUM-NUM-OF-LCH 


Octet ... 


Future use | PHY-MODE-LCH 


Octet ... 


NB-OF-LCH 


Octet ... 


MIN-NB-OF-LCH 


Octet ... 


start-pointer 


Octet ... 


start-pointer Future use 


Octet ... 


repetition-counter 


Octet ... 


repetition-counter frame-count 


Octet ... 


Not used 


Octet ... 




Octet 51 1 



Total length = 6-i-L-i- 14xNif asymmetric duplex with fixed capacity agreement and with FEC. 
Total length = 6-i-L-i-6xNif asymmetric duplex with basic allocation and with FEC. 
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Total length = 6 + L + 7xNif symmetric duplex with fixed capacity agreement and with FEC. 

Total length = 6 + L + 3xNif symmetric duplex with basic allocation and with FEC. 

Total length = 6 + L + 3xNif simplex with basic allocation and with FEC. 

Total length = 6 + L + 7xNif simplex with fixed capacity agreement and with FEC. 

Total length = 6 + L+ 12xNif asymmetric duplex with fixed capacity agreement and without FEC. 

Total length = 6 + L + 4xNif asymmetric duplex with basic allocation and without FEC. 

Total length = 6 + L + 6xNif symmetric duplex with fixed capacity agreement and without FEC. 

Total length = 6 + L + 2xNif symmetric duplex with basic allocation and without FEC. 

Total length = 6 + L + 2xNif simplex with basic allocation and without FEC. 

Total length = 6 + L + 6xNif simplex with fixed capacity agreement and without FEC. 

Fixed Slot Allocation (FSA) may be used in any EC mode and with or without FEC. When using unacknowledged 
mode, a MT does not have to decode the FCCH once the connection is set up. When using acknowledged mode, a MT 
shall decode the FCCH, because SCHs for acknowledgements and discards are granted in basic allocation mode. Only 
LCHs can be allocated with FSA. In the following the total length of the PDU is given for the unacknowledged mode: 

Total length = 6 + L+ ISxNif asymmetric duplex with FSA and with FEC. 

Total length = 6 + L + 9xNif symmetric duplex with FSA and with FEC. 

Total length = 6 + L + 9xNif simplex with FSA and with FEC. 

Total length = 6 + L+ 16xNif asymmetric duplex with FSA and without FEC. 

Total length = 6 + L + 8xNif symmetric duplex with FSA and without FEC. 

Total length = 6 + L + 8xNif simplex with FSA and without FEC. 
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A.4.7 RLC-MODIFY encoding (OAP/OMT) 





8 


7 1 6 1 5 1 4 1 3 


2 1 1 


Octet 4 


Future use 


CL-CONN-ATTR-LENGTH L) 


#of DUC:s 


Octet 5 


#of DUC:s(N) 


Future use 


Octet 6 


DUC1- 
DIRECTION 


DLCC-ID 




CL-CONN-ATTR 


Octet 6 -H L 


Octet Y 


DUC1-FW-TYPE-0F- 
ALLOCATION 


Future 
use 


CYCLIC-PREFIX 


FEC- 
USED 


EC-MODE 


Octet ... 


DUC1-FW-NUM-0F- 
RETRANSMISSIONS 


Future use 


DUC1-FW-AR0-WIN- 
SIZE 




FEC-FW 


Future Use 


Octet .. 




PER-#-MAC-FRAME (SCH) 


PER-#-MAC-FRAME (LCH) 


Octet .. 




REQ SCH 1 PHY-MODE-SCH 


PHY-MODE-LCH 


Octet .. 




REOUESTED-NUM-OF-LCH 


Octet .. 




MINUMUM-NUM-OF-LCH 


Octet .. 




Future use | PHY-MODE-LCH 


Octet .. 




NB-OF-LCH 


Octet .. 




MIN-NB-OF-LCH 


Octet .. 




start-pointer 


Octet .. 




start-pointer Future use 


Octet .. 




repetition-counter 


Octet .. 




repetition-counter frame-count 


Octet X 


DUC1-BW-TYPE-0F- 
ALLOCATION 


Future 
use 


CYCLIC-PREFIX 


FEC- 
USED 


EC-MODE 


Octet ... 


DUC1-BW-NUM-0F- 
RETRANSMISSIONS 


Future use 


DUC1-BW-AR0-WIN- 
SIZE 




FEC-BW 


Future Use 


Octet .. 




PER-#-MAC-FRAME (SCH) 


PER-#-MAC-FRAME (LCH) 


Octet .. 




REQ SCH 1 PHY-MODE-SCH 


PHY-MODE-LCH 


Octet .. 




REOUESTED-NUM-OF-LCH 


Octet .. 




MINUMUM-NUM-OF-LCH 


Octet .. 




Future use | PHY-MODE-LCH 


Octet .. 




NB-OF-LCH 


Octet .. 




MIN-NB-OF-LCH 


Octet .. 




start-pointer 


Octet .. 




start-pointer Future use 


Octet .. 




repetition-counter 


Octet .. 




repetition-counter frame-count 


Octet .. 




Not used 


Octet .. 




Octet 51 

















Total length = 6-i-L-i- 14xNif asymmetric duplex with fixed capacity agreement and with FEC. 

Total length = 6-i-L-i-6xNif asymmetric duplex with basic allocation and with FEC. 

Total length = 6-i-L-i-7xNif symmetric duplex with fixed capacity agreement and with FEC. 

Total length = 6-i-L-i-3xNif symmetric duplex with basic allocation and with FEC. 

Total length = 6-i-L-i-3xNif simplex with basic allocation and with FEC. 

Total length = 6-i-L-i-7xNif simplex with fixed capacity agreement and with FEC. 

Total length = 6-i-L-i- 12xNif asymmetric duplex with fixed capacity agreement and without FEC. 

Total length = 6-i-L-i-4xNif asymmetric duplex with basic allocation and without FEC. 

Total length = 6-i-L-i-6xNif symmetric duplex with fixed capacity agreement and without FEC. 

Total length = 6-i-L-i-2xNif symmetric duplex with basic allocation and without FEC. 
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Total length = 6 + L + 2xNif simplex with basic allocation and without FEC 

Total length = 6 + L + 6xNif simplex with fixed capacity agreement and without FEC 

Fixed Slot Allocation (FSA) may be used in any EC mode and with or without FEC. When using unacknowledged 
mode, a MT does not have to decode the FCCH once the connection is set up. When using acknowledged mode, a MT 
shall decode the FCCH, because SCHs for acknowledgements and discards are granted in basic allocation mode. Only 
LCHs can be allocated with FSA. In the following the total length of the PDU is given for the unacknowledged mode: 

Total length = 6 + L+ ISxNif asymmetric duplex with FSA and with FEC. 

Total length = 6 + L + 9xNif symmetric duplex with FSA and with FEC. 

Total length = 6 + L + 9xNif simplex with FSA and with FEC. 

Total length = 6 + L+ 16xNif asymmetric duplex with FSA and without FEC. 

Total length = 6 + L + 8xNif symmetric duplex with FSA and without FEC. 

Total length = 6 + L + 8xNif simplex with FSA and without FEC. 

A.4.8 RLC-MODIFY-ACK encoding (OAP/OMT) 





8 


7 1 6 1 5 1 4 1 3 


2 1 1 


Octet 4 


Future use 


CL-CONN-ATTR-LENGTH (L) 


# of DLCC+CL-CON-ATT 


Octet 5 


# of DLCC+CL-CON-ATT (N) 


Future use 


Octet ... 


Future use 


DLCC-ID-1 


Octet ... 


CL-CONN-ATTR-1 


Octet ... 


Octet ... 


Future use | DLCC-ID-2 


Octet ... 


CL-CONN-ATTR-2 


Octet 5 + (L + 1 ) X N 


Octet ... 


Not used 


Octet... 


Octet 51 











Total length = 5 + (L + 1) x N. 



A.4.9 RLC-RESET, RLC-RESET-ACK encoding 





8 1 7 1 6 


5 


4 1 3 1 2 1 


1 


Octet 4 


Future use 


#ofDLCC:s(N) 


Octet 5 


Future use 


DLCC-ID-1 


Octet 6 


Future use 


DLCC-ID... 


Octet 4 -^ N 


Future use 




Octet... 


Not used 


Octet... 


Octet 51 
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A.4.10 RLC-DM-SETUP encoding (OAP/OMT) 





8 |7|6|5| 4 1 3 |2|1 


Octet 4 


MAC- ID 


Octet 5 


CL-ID 


Octet 6 


DUC-EXT-IND 


CL-CONN-ATTR-LENGTH (L) 


CL-COMMON- 
ATTR-LENGTH 


Octet 7 


CL-COMMON-ATTR-LENGTH 


Future 
use 


#of DUC:s(N) 


Octet 8 


DUC1 -DIRECTION | DLCC-ID 




CL-CONN-ATTR 




Octet Y 


DUC1-FW-TYPE-0F- 
ALLOCATION 


Future 
use 


CYCLIC-PREFIX 


FEC-USED 


EC-MODE 


Octet ... 


DUC1 -FW-NUM-OF-RETRANSMISSIONS 


Future use 


DUC1-FW-ARQ-WIN-SIZE 1 




FEC-FW 


Future Use 


Octet ... 


PER-#-MAC-FRAME (SCH) 


PER-#-MAC-FRAME(LCH) 


Octet ... 


REOSCH 1 PHY-MODE-SCH 


PHY-MODE-LCH 


Octet ... 


REQUESTED-NUM-OF-LCH 


Octet ... 


MINUMUM-NUM-OF-LCH 


Octet ... 


Future use | PHY-MODE-LCH 


Octet ... 


NB-OF-LCH 


Octet ... 


MIN-NB-OF-LCH 


Octet ... 


start-pointer 


Octet ... 


start-pointer Future use 


Octet ... 


repetition-counter 


Octet ... 


repetition-counter 


frame-count 


Octet X 


DUC1-BW-TYPE-0F- 
ALLOCATION 


Future 
use 


CYCLIC-PREFIX 


FEC-USED 


EC-MODE 














Octet ... 


DUC1 -BW-NUM-OF-RETRANSMISSIONS 


Future use 


DUC1-BW-ARQ-WIN-SIZE | 




FEC-BW 


Future Use 


Octet ... 


PER-#-MAC-FRAME (SCH) 


PER-#-MAC-FRAME (LCH) 


Octet ... 


REO SCH PHY-MODE-SCH 


PHY-MODE-LCH 


Octet ... 


REQUESTED-NUM-OF-LCH 


Octet ... 


MINUMUM-NUM-OF-LCH 


Octet ... 


Future use | PHY-MODE-LCH 


Octet ... 


NB-OF-LCH 


Octet ... 


MIN-NB-OF-LCH 


Octet ... 


start-pointer 


Octet ... 


start-pointer Future use 


Octet ... 


repetition-counter 


Octet ... 


repetition-counter frame-count 


Octet ... 


CL-COMMON-AI IK 


Octet ... 


Octet ... 


Octet ... 


Not used 


Octet ... 


Octet 51 















Y = 8 H- L. 

X = 8-i-L-i-6if asymmetric duplex with polling and ARQ or FEC. 
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A.4.1 1 RLC-DM-CONNECT encoding (OAP/OMT) 





8|7|6|5| 4 |3|2|1 


Octet 4 


MAC- ID 


Octet 5 


CL-ID 


Octet 6 


Future 

use 


CL-CONN-ATTR-LENGTH (L) 


#ofDUC:s 


Octet 7 


#ofDUC:s(N) 


Future use 


Octet 8 


DUC1-DIRECTI0N 


DLCC-ID 




CL-CONN-ATTR 




Octet Y 


DUC1 -FW-TYPE-OF-ALLOCATION 


Future 
use 


CYCLIC-PREFIX 


FEC-USED 


EC-MODE 


Octet ... 


DUC1-FW-NUM-0F-RETRANSMISSI0NS 


Future use 


DUC1-FW-ARQ-WIN-SIZE 




FEC-FW 


Future Use 


Octet ... 


PER-#-MAC-FRAME (SCH) 


PER-#-MAC-FRAME (LCH) 


Octet ... 


REQSCH 1 PHY-MODE-SCH 


PHY-MODE-LCH 


Octet ... 


REQUESTED-NUM-OF-LCH 


Octet ... 


MINUMUM-NUM-OF-LCH 


Octet ... 


Future use | PHY-MODE-LCH 


Octet ... 


NB-OF-LCH 


Octet ... 


MIN-NB-OF-LCH 


Octet ... 


start-pointer 


Octet ... 


start-pointer Future use 


Octet ... 


repetition-counter 


Octet ... 


repetition-counter 


frame-count 


Octet X 


DUC1-BW-TYPE-OF-ALLOCATION Future use 


CYCLIC-PREFIX 


FEC-USED 1 EC-MODE 


Octet ... 


DUC1-BW-NUM-OF-RETRANSMISSIONS 


Future use 


DUC1-BW-ARQ-WIN-SIZE 




FEC-BW 


Future Use 


Octet ... 


PER-#-MAC-FRAME (SCH) 


PER-#-MAC-FRAME (LCH) 


Octet ... 


REQSCH 1 PHY-IVIODE-SCH 


PHY-MODE-LCH 


Octet ... 


REQUESTED-NUM-OF-LCH 


Octet ... 


MINUMUM-NUM-OF-LCH 


Octet ... 


Future use | PHY-MODE-LCH 


Octet ... 


NB-OF-LCH 


Octet ... 


MIN-NB-OF-LCH 


Octet ... 


start-pointer 


Octet ... 


start-pointer Future use 


Octet ... 


repetition-counter 


Octet ... 


repetition-counter frame-count 


Octet ... 


Not used 


Octet ... 


Octet 51 

















A.4.12 RLC-DM-CONNECT-ACK encoding (OAP/OIVIT) 





8 1 7 


6 1 5 1 4 1 3 


1 2 1 1 1 


Octet 4 


MAC- ID 


Octet 5 


CL-ID 


Octet 6 


Future use | 


CL-CONN-ATTR-LENGTH (L) 


#0fDLCC:s-i-CL-ATTR 


Octet 7 


# Of DLCCs (N) 


Future use 


Octet 8 


Future use 


DLCC-ID-1 


Octet... 


CL-CONN-ATTR-1 | 


Octet... 


Future use 


DLCC-ID-N 




Octet... 


CL-CONN-ATTR-N 


Octet 8 -F L X N 


Octet... 


Not used 


Octet... 


Octet 51 
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A.4.13 RLC-DM-CONNECT-COMPLETE encoding (OAP/OMT) 





8 1 7 1 6 1 


5 1 4 1 3 1 2 1 


1 1 


Octet 4 


MAC- ID 1 


Octet 5 


Future use 


1 # of DLCC:s (N) 


1 


Octet 6 


Future use 


DLCC-ID-1 


Octet... 


Future use 




Octet 5 + N 


Future use 


DLCC-ID-N 


Octet 6 + N 


Not used 


Octet... 


Octet 51 



A.4.14 RLC-DM-RELAY-SETUP encoding (OAP/OIVIT) 





8 |7|6|5| 4 |3|2|1 


Octet 4 


MAC- ID 


Octet 5 


CL-ID 


Octet 6 


DUC-EXT-IND 


CL-CONN-ATTR-LENGTH (L) 


CL-COMMON-ATTR- 
LENGTH 


Octet 7 


CL-COMMON-ATTR-LENGTH 


Future 
use 


#of DUC;s(N) 


Octet 8 


DUC1-DIRECTI0N | DLCC-ID 




CL-CONN-ATTR 




Octet Y 


DUC1 -FW-TYPE-OF-ALLOCATION 


Future 
use 


CYCLIC-PREFIX 


FEC-USED 


EC-MODE 


Octet ... 


DUC1 -FW-NUM-OF-RETRANSMISSIONS 


Future use 


DUC1-FW-AR0-WIN-SIZE 1 




FEC-FW 


Future Use 


Octet ... 


PER-#-MAC-FRAME (SCH) 


PER-#-MAC-FRAME (LCH) 


Octet ... 


REOSCH 1 PHY-MODE-SCH 


PHY-MODE-LCH 


Octet ... 


REQUESTED-NUM-OF-LCH 


Octet ... 


MINUMUM-NUM-OF-LCH 


Octet ... 


Future use | PHY-MODE-LCH 


Octet ... 


NB-OF-LCH 


Octet ... 


MIN-NB-OF-LCH 


Octet ... 


start-pointer 


Octet ... 


start-pointer Future use 


Octet ... 


repetition-counter 


Octet ... 


repetition-counter 


frame-count 


Octet X 


DUC1-BW-TYPE-OF-ALLOCATION 


Future 
use 


CYCLIC-PREFIX 


FEC-USED 


EC-MODE 


Octet ... 


DUC1 -BW-NUM-OF-RETRANSMISSIONS 


Future use 


DUC1-BW-AR0-WIN-SIZE 1 




FEC-BW 


Future Use 


Octet ... 


PER-#-MAC-FRAME (SCH) 


PER-#-MAC-FRAME (LCH) 


Octet ... 


REOSCH 1 PHY-MODE-SCH 


PHY-MODE-LCH 


Octet ... 


REQUESTED-NUM-OF-LCH 


Octet ... 


MINUMUM-NUM-OF-LCH 


Octet ... 


Future use | PHY-MODE-LCH 


Octet ... 


NB-OF-LCH 


Octet ... 


MIN-NB-OF-LCH 


Octet ... 


start-pointer 


Octet ... 


start-pointer Future use 


Octet ... 


repetition-counter 


Octet ... 


repetition-counter frame-count 


Octet ... 


CL-COMMON-ATTR 


Octet ... 


Octet ... 


Octet ... 


Not used 


Octet ... 


Octet 51 
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A.4.15 RLC-DM-RELAY-SETUP-ACK encoding (OAP/OMT) 





8 1 7 


6 1 5 1 4 1 3 


2 1 1 1 


Octet 4 


MAC-ID 1 


Octet 5 


Future 


CL-CONN-ATTR-LENGTH 


#ofDLCC:s 1 


Octet 6 


# of DLCCs 


Future use 


Octet 7 


Future use 


DLCC-ID-1 


Octet... 


CL-CONN-ATTR-1 


Octet... 


Future use 


DLCC-ID 




Octet ... 


CL-CONN-ATTR 


Octet ... 


Not used 


Octet ... 


Octet 51 



A.4.16 RLC-DM-MODIFY-REQ encoding (OAP/OIVIT) 





8 |7|6| 5 1 4 |3|2|1 


Octet 4 


MAC-ID 


Octet 5 


Future 
use 


CL-CONN-ATTR-LENGTH (L) 


#of DUC:s 


Octet 6 


#of DUC:s(N) 


Future use 


Octet 7 


DUC1- 
DIRECTION 


DLCC-ID 




CL-CONN-ATTR 




Octet Y 


DUC1-FW-TYPE-0F-ALL0CATI0N 


Future 
use 


CYCLIC-PREFIX 


FEC-USED 


EC-MODE 


Octet ... 


DUC1-FW-NUM-0F- 
RETRANSMISSIONS 


Future use 


DUC1-FW-AR0-WIN- 
SIZE 




FEC-FW 


Future Use 


Octet ... 


PER-#-MAC-FRAME (SCH) 


PER-#-MAC-FRAME (LCH) 


Octet ... 


REQSCH 1 PHY-MODE-SCH 


PHY-MODE-LCH 


Octet ... 


REOUESTED-NUM-OF-LCH 


Octet ... 


MINUMUM-NUM-OF-LCH 


Octet ... 


Future use 1 PHY-MODE-LCH 


Octet ... 


NB-OF-LCH 


Octet ... 


MIN-NB-OF-LCH 


Octet ... 


start-pointer 


Octet ... 


start-Dointer Future use 


Octet ... 


repetition-counter 


Octet ... 


repetition-counter 


frame-count | 


Octet X 


DUC1-BW-TYPE-OF-ALLOCATION Future use 


CYCLIC-PREFIX 


FEC-USED 1 EC-MODE 


Octet ... 


DUC1-BW-NUM-0F- 


Future use 


DUC1-BW-ARQ-WIN- 




FEC-BW 


Future Use 


Octet ... 


PER-#-MAC-FRAME (SCH) 


PER-#-MAC-FRAME (LCH) 


Octet ... 


REQSCH 1 PHY-MODE-SCH 


PHY-MODE-LCH 


Octet ... 


REOUESTED-NUM-OF-LCH 


Octet ... 


MINUMUM-NUM-OF-LCH 


Octet ... 


Future use PHY-MODE-LCH 


Octet ... 


NB-OF-LCH 


Octet ... 


MIN-NB-OF-LCH 


Octet ... 


start-pointer 


Octet ... 


start-pointer Future use 


Octet ... 


repetition-counter 


Octet ... 


repetition-counter frame-count 


Octet ... 


Not used 


Octet ... 


Octet 51 
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A.4.17 RLC-DM-MODIFY encoding (OAP/OMT) 





8 |7|6|5| 4 |3|2|1 


Octet 4 


MAC- ID 


Octet 5 


Future use | CL-CONN-ATTR-LENGTH (L) | # of DUC:s 


Octet 6 


#ofDUC:s(N) 


Future use 


Octet 7 


DUC1 -DIRECTION 


DLCC-ID 




CL-CONN-ATTR 




Octet Y 


DUC1 -FW-TYPE-OF-ALLOCATION 


Future 
use 


CYCLIC-PREFIX 


FEC-USED 


EC-MODE 


Octet ... 


DUC1-FW-NUM-0F- 
RETRANSMISSIONS 


Future use 


DUC1-FW-ARQ-WiN-SIZE 




FEC-FW 


Future Use 


Octet .. 




PER-#-MAC-FRAME (SCH) 


PER-#-MAC-FRAME (LCH) 


Octet .. 




REQSCH 1 PHY-MODE-SCH 


PHY-MODE-LCH 


Octet .. 




REQUESTED-NUM-OF-LCH 


Octet .. 




MINUMUM-NUM-OF-LCH 


Octet .. 




Future use | PHY-MODE-LCH 


Octet .. 




NB-OF-LCH 


Octet .. 




MIN-NB-OF-LCH 


Octet .. 




start-pointer 


Octet .. 




start-pointer Future use 


Octet .. 




repetition-counter 


Octet .. 




repetition-counter 


frame-count 


Octet X 


DUC1 -BW-TYPE-OF-ALLOCATION 


Future 
use 


CYCLIC-PREFIX 


FEC-USED 


EC-MODE 


Octet ... 


DUC1-BW-NUM-0F- 
RETRANSIVIISSIONS 


Future use 


DUC1-BW-ARQ-WIN-SIZE 




FEC-BW 


Future Use 


Octet .. 




PER-#-MAC-FRAME (SCH) 


PER-#-MAC-FRAME (LCH) 


Octet .. 




REQSCH 1 PHY-MODE-SCH 


PHY-MODE-LCH 


Octet .. 




REQUESTED-NUM-OF-LCH 


Octet .. 




MINUMUM-NUM-OF-LCH 


Octet .. 




Future use | PHY-MODE-LCH 


Octet .. 




NB-OF-LCH 


Octet .. 




MIN-NB-OF-LCH 


Octet .. 




start-pointer 


Octet .. 




start-pointer Future use 


Octet .. 




repetition-counter 


Octet .. 




repetition-counter frame-count 


Octet .. 




Not used 


Octet .. 




Octet 51 















A.4.18 RLC-DM-MODIFY-ACK encoding (OAP/OiVIT) 





8 |7|6|5|4|3|2|1 


Octet 4 


MAC-ID 


Octet 5 


CL-CONN-ATTR-LENGTH # of DLCC:s-^CL-CONN-ATTR 


Octet 6 


#ofDLCCs 1 Future use 


Octet 7 


Future use | DLCC-ID-1 


Octet... 


CL-CONN-ATTR-1 




Future use | DLCC-ID... 




CL-CONN-ATTR... 




Not used 




Octet 51 
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A.4.19 RLC-DM-MODIFY-COMPLETE encoding (OAP/OMT) 





8 1 7 1 6 


5 1 4 1 3 1 2 


1 1 


Octet 4 


MAC-ID 1 


Octet 5 


Future use 


1 # of DLCC:s 


1 


Octet 6 


Future use 


DLCC-ID-1 


Octet 7 


Future use 


DLCC-ID... 


Octet... 


Not used 


Octet... 


Octet 51 



A.4.20 RLC-DM-RELAY-MODIFY encoding (OAP/OIVIT) 





8 |7|6|5| 4 |3|2|1 


Octet 4 


MAC- ID 


Octet 5 


Future use | CL-CONN-ATTR-LENGTH (L) | # of DUC:s 


Octet 6 


#of DUC:s(N) 


Future use 


Octet 7 


DUC1-DIRECTI0N 


DLCC-ID 




CL-CONN-ATTR 




Octet Y 


DUC1 -FW-TYPE-OF-ALLOCATION 


Future 
use 


CYCLIC-PREFIX 


FEC-USED 


EC-MODE 


Octet ... 


DUC1-FW-NUM-OF-RETRANSMISSIONS 


Future use 


DUC1-FW-ARQ-WIN-SIZE 




FEC-FW 


Future Use 


Octet ... 


PER-#-MAC-FRAME(SCH) 


PER-#-MAC-FRAME (LCH) 


Octet ... 


REQSCH 1 PHY-MODE-SCH 


PHY-MODE-LCH 


Octet ... 


REQUESTED-NUM-OF-LCH 


Octet ... 


MINUMUM-NUM-OF-LCH 


Octet ... 


Future use | PHY-MODE-LCH 


Octet ... 


NB-OF-LCH 


Octet ... 


MIN-NB-OF-LCH 


Octet ... 


start-pointer 


Octet ... 


start-pointer Future use 


Octet ... 


repetition-counter 


Octet ... 


repetition-counter 


frame-count 


Octet X 


DUC1-BW-TYPE-OF-ALLOCATION 


Future 
use 


CYCLIC-PREFIX 


FEC-USED 


EC-MODE 


Octet ... 


DUC1-BW-NUM-OF-RETRANSMISSIONS 


Future use 


DUC1 -BW-ARQ-WIN-SIZE 




FEC-BW 


Future Use 


Octet ... 


PER-#-MAC-FRAME(SCH) 


PER-#-MAC-FRAME (LCH) 


Octet ... 


REQSCH 1 PHY-MODE-SCH 


PHY-MODE-LCH 


Octet ... 


REQUESTED-NUM-OF-LCH 


Octet ... 


MINUMUM-NUM-OF-LCH 


Octet ... 


Future use | PHY-MODE-LCH 


Octet ... 


NB-OF-LCH 


Octet ... 


MIN-NB-OF-LCH 


Octet ... 


start-pointer 


Octet ... 


start-pointer Future use 


Octet ... 


repetition-counter 


Octet ... 


repetition-counter frame-count 


Octet ... 


Not used 


Octet ... 


Octet 51 
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A.4.21 RLC-DM-RELAY-MODIFY-ACK encoding (OAP/OMT) 





8 1 7 


6 1 5 1 4 1 3 


2 1 1 


Octet 4 


MAC- ID 


Octet 5 


Future use 


CL-CONN-ATTR-LENGTH 


# of DLCC:s 


Octet 6 


# of DLCCs 


Future use 


Octet 7 


Future use 


DLCC-ID-1 


Octet... 


CL-CONN-ATTR-1 


Octet... 


Future use 


DLCC-ID-2 




Octet... 


CL-CONN-ATTR-2 


Octet... 


Not used 


Octet... 


Octet 51 



A.4.22 RLC-DM-RELEASE encoding (OAP/OIVIT) 





8 1 7 1 6 


5 1 4 1 3 1 2 


1 


Octet 4 


MAC-ID 


Octet 5 


CAUSE 


1 # of DLCC:s 




Octet 6 


Future use 


DLCC-ID-1 


Octet 7 


Future use 




Octet... 


Future use 


DLCC-IDN 


Octet... 


Not used 


Octet... 


Octet 51 



A.4.23 RLC-DIVI-RELEASE-ACK encoding (OAP/OIVIT) 





8 1 7 1 6 


5 1 4 1 3 1 2 


1 


Octet 4 


MAC-ID 


Octet 5 


Future use 


1 # of DLCC:s 




Octet 6 


Future use 


DLCC-ID-1 


Octet 7 


Future use 




Octet... 


Future use 


DLCC-ID-N 


Octet... 


Not used 


Octet... 


Octet 51 



A.4.24 RLC-DM-RELAY-RELEASE encoding (OAP/OMT) 





8 1 7 1 6 


5 1 4 1 3 1 2 


1 


Octet 4 


MAC-ID 


Octet 5 


CAUSE 


1 # of DLCC:s 




Octet 6 


Future use 


DLCC-ID-1 


Octet 7 


Future use 




Octet... 


Future use 


DLCC-ID-N 


Octet... 


Not used 


Octet... 


Octet 51 
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A.4.25 RLC-DM-RELAY-RELEASE-ACK encoding (OAP/OMT) 





8|7|6|5|4|3|2|1 


Octet 4 


MAC-ID 


Octet 5 


Future use | # of DLCC:s 


Octet 6 


Future use 


DLCC-ID-1 


Octet 7 


Future use 




Octet... 


Future use 


DLCC-IDN 


Octet... 


Not used 


Octet... 


Octet 51 







A.4.26 RLC-DM-RESET, RLC-DM-RESET-ACK encoding 
(OAP/OIVIT) 





8 1 7 1 6 


5 1 4 1 3 1 2 


1 


Octet 4 


MAC-ID 


Octet 5 


Future use 


1 # of DLCC:s 




Octet 6 


Future use 


DLCC-ID-1 


Octet 7 


Future use 


DLCC-ID... 


Octet... 


Future use 




Octet... 


Not used 


Octet... 


Octet 53 



A.4.27 RLC-TEST-IVIODE-SETUP encoding 





8 1 7 1 6 1 5 


4 1 3 1 2 1 1 


Octet 4 


TEST-MODE-TYPE 


PHY-MODE-LCH-FW/BW 


Octet 5 


TEST-LOOP-BACK-DELAY 


TEST-REPEAT-DELAY 


Octet 6 


#-TEST-LCH 1 Future use 


Octet 7 


DUC-DIRECTION | DLCC-ID 


Octet 8 


DUC-FWBW-TYPE-OF-ALLOC.AT | Future 


CYCLIC-PREFIX 


FEC- 1 EC-MODE 


Octet 9 


DUC-FWBW-NUM-OF- 


Future 


DUC-FWBWARO-WIN-SIZE 


Octet 10 


FEC-FW 


Future Use 


Octet 1 1 


PER-#-MAC-FRAME (SCH) 


PER-#-MAC-FRAME (LCH) 


Octet 12 


REG 1 PHY-MODE-SCH 


PHY-MODE-LCH 


Octet 13 


REOUESTED-NUM-OF-LCH 


Octet 14 


MINUMUM-NUM-OF-LCH 


Octet 15 


Future use 1 PHY-MODE-LCH 


Octet 16 


NB-OF-LCH 


Octet 17 


MIN-NB-OF-LCH 


Octet 18 


start-Dointer 


Octet 19 


start-pointer Future use 


Octet 20 


repetition-counter 


Octet 21 


repetition-counter frame-count 


Octet ... 


Not used 


Octet ... 


Octet 51 
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A.4.28 RLC-TEST-MODE-CONNECT encoding 





8 1 7 1 6 1 5 


4 1 3 1 2 1 1 


Octet 4 


TEST-MODE-TYPE 


PHY-MODE-LCH-FW/BW 


Octets 


TEST-LOOP-BACK-DELAY 


TEST-REPEAT-DELAY 


Octet 6 


#-TEST-LCH 1 Future use 


Octet 7 


DUC-DIRECTION | DLCC-ID 


Octet 8 


DUC-FWBW-TYPE-OF-ALLOC.AT 


Future 
use 


CYCLIC-PREFIX 


FEC- 
USED 


EC-MODE 


Octet 9 


DUC-FWBW-NUM-OF- 
RETRANSMISSIONS 


Future 
use 


DUC-FWBWARQ-WIN-SIZE 


Octet 10 


FEC-FW 


Future Use 


Octet 1 1 


PER-#-MAC-FRAME (SCH) 


PER-#-MAC-FRAME (LCH) 


Octet 12 


REO 
SCH 


PHY-MODE-SCH 


PHY-MODE-LCH 


Octet 13 


REOUESTED-NUM-OF-LCH 


Octet 14 


MINUMUM-NUM-OF-LCH 


Octet 15 


Future use PHY-MODE-LCH 


Octet 16 


NB-OF-LCH 


Octet 17 


MIN-NB-OF-LCH 


Octet 18 


start-pointer 


Octet 19 


start-pointer Future use 


Octet 20 


repetition-counter 


Octet 21 


repetition-counter frame-count 


Octet ... 


Not used 


Octet ... 


Octet 51 















A.4.29 RLC-TEST-MODE-CONNECT-ACK encoding 





8 1 7 


6 


5 14 13 


2 


1 


Octet 4 


Future use 


DLCC-ID 


Octet ... 


Not used 


Octet ... 


Octet 51 



A.5 Transfer Syntax Tables for SCH ACF messages 
A.5.1 RLC-RBCH-ASSOCIATION-REQUEST encoding (OIVIT) 





8 


7 


6 15 14 


3 


2 1 1 


Octet 3 


-==3 


AP-ID 


Octet 4 


AP-ID 


Octet 5 






Future use 




NET-ID 


Octet 6 


NET-ID 


Octet 7 


MAC-ID 



A.5.2 RLC-IVIAC-ID-ASSIGN encoding 





8 


7 


6 


1 5 1 4 1 


3 


2 1 1 


Octet 3 




Future use 


Octet 4 


MAGIC 


Octet 5 


Octet 6 


RLC-VERSION 


Octet 7 


MAC-ID 
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A.5.3 RLC-MAC-ID-ASSIGN-ACK encoding 





8 


7 


6 


5 1 4 


1 3 1 


2 


1 


Octet 3 




Future use 


Octet 4 


MAGIC 


Octet 5 


Octet 6 


MAC-ID 


Octet 7 


MAC-ID1 



A.5.4 RLC-MAC-ID-ASSIGN-NACK encoding 





8 


7 


6 


5 1 4 


1 3 1 


2 


1 


Octet 3 






Future use 


Octet 4 


MAGIC 


Octet 5 


Octet 6 


Future use 


Octet 7 



A.5.5 RLC- RLC-COiVIIVION-KEY-ACTIVATE encoding (GAP) 





8 


7 


6 


5 1 4 1 3 1 


2 


1 


Octet 3 




Future use 


Octet 4 


KEY-ID 


Octet 5 


LAST-MAC-FRAME 


Octet 6 


Octet 7 


Not used 



A.5.6 RLC-DISASSGCIATIGN encoding 





8 1 7 1 6 


1 5 1 4 1 3 


2 1 1 


Octet 3 




Future use 


Octet 4 


Future use 


1 DISASSOCIATION-CAUSE 


Octet 5 


Future use 


Octet 6 


Octet 7 


MAC-ID (if sent in uplink) 



A.5.7 RLG-DISASSGCIATIGN-AGK encoding 





8 


7 


6 


1 5 1 4 1 


3 


2 1 1 


Octet 3 




Future use 


Octet 4 


Future use 


Octet 5 


Octet 6 


Octet 7 


MAC-ID (if sent in uplink) 
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A.5.8 RLC-PROCEEDING encoding 





8 1 7 1 6 1 5 1 4 1 


3 


2 


1 


Octet 3 




Future 
use 


SCH-LCH 


Octet 4 


Proceeded-PDU-type 


Octet 5 


Future use 


EXTENSION-TYPE 


Octet 6 


Future use 


Octet 7 


MAC-ID (if sent in uplink) 



A.5.9 RLC-UNICAST-KEY-ACTIVATE encoding (GAP) 





8 


7 


6 


5 1 4 1 3 1 


2 


1 


Octet 3 




Future use 


Octet 4 


LAST-MAC-FRAME 


Octet 5 


Octet 6 


Not used 


Octet 7 



A.6 Transfer Syntax Tables for SCH RRG messages 

A.6.1 RLC-SECTGR-HANDGVER-REQUEST encoding 
(GAP/GIVIT) 





8 


7 


6 


5 1 4 


3 


2 1 1 


Octet 3 


"" 






Future Use 


Octet 4 






Future use 




SECTOR-ID 


Octet 5 


Future use 


Octet 6 


Octet 7 


MAC-ID 



A.6.2 RLG-SECTGR-HANDGVER-ACK encoding (GAP/GIVIT) 

Empty PDU. 





8 1 7 1 6 


5 1 4 1 3 1 2 1 1 


Octet 3 


^^1^^^^^^ 


Future use 


Octet ... 


Future use 


Octet 7 







A.6.3 RLC-HANDGVER-NGTIFY encoding (GAP/GMT) 





8 


1 7 1 6 1 5 1 4 


3 


2 


1 


Octet 3 




AP-IDpr 


NET-IDpr 


Octet 4 




HANDOVER-CAUSE | 


AP-ID 


Octet 5 




AP-ID 


1 NET-ID 


Octet 6 


NET-ID 


Octet 7 


MAC-ID 
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A.6.4 RLC-HANDOVER-REQUEST encoding (OAP/OMT) 





8 1 7 


1 6 1 


5 1 4 


1 3 


2 1 1 


Octet 3 




AP-ID-OLD 


Octet 4 


AP-ID-OLD 
AP-ID-OLD 


Octet 5 


MAC-ID-OLD 
NET-ID-OLD 


Octet 6 


NET-ID-OLD 
NET-ID-OLD 


Octet 7 


NET-ID-OLD 


DUC-EST 




Future use 





A.6.5 RLC-HANDOVER-REQUEST-NACK encoding (OAP/OIVIT) 





8 1 7 1 6 


5 1 4 


1 3 1 2 1 1 


Octet 3 




Future use 
AP-ID-OLD 


Octet 4 


MAC-ID-OLD 


Octet 5 


Future use 


AP-ID-OLD 


Octet 6 


AP-ID-OLD 


1 NET-ID-OLD 


Octet 7 


NET-ID-OLD 



A.6.6 RLC-HO-INFO-DISTRIBUTION-ACK encoding (OAP/OIVIT) 





8 


7 


6 


5 1 4 


3 


2 1 1 


Octet 3 




Future use 


Octet 4 


Future use 


Octet 5 


Octet 6 


Octet 7 


MAC-ID 



A.6.7 RLC-FORCE-HANDOVER encoding (OAP/OMT) 





8 7 6 


5 


4 


3 1 2 1 1 


Octet 3 


^H 


Return 


Future 
use 


Cause:TrafLoad/Badlink/Operator 

Badlink 

Operator 


Octet 4 


FREQUENCY-INDEX 
NET-ID 


Octet 5 


AP-ID 
AP-ID 


Octet 6 


AP-ID Future use 


1 NET-ID 


Octet 7 


NET-ID 
Future use 



A.6.8 RLC-FORCE-HANDOVER-ACK encoding (OAP/OMT) 





8 


7 


6 


5 1 4 


3 


2 1 1 


Octet 3 




Future use 


Octet 4 


Future use 


Octet 5 


Octet 6 


Octet 7 


MAC-ID 
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A.6.9 RLC-AP-ABSENCE encoding (OAP) 





8 


7 


6 


5 


4 1 3 1 2 1 


1 


Octet 3 




Future 
use 


FIRST-MAC-FRAME 


Octet 4 


LAST-MAC-FRAME 


Octet 5 


Octet 6 


Future use 


Octet 7 



A.6.10 RLC-DFS-MT-INIT-REPORT-REQUEST encoding (OIVIT) 





8 1 7 1 6 1 5 1 4 1 3 


2 1 1 


Octet 3 




MEASUREMENT-TYPE 


Octet 4 


FREQUENCY-INDEX 
FREQUENCY-INDEX 


Octet 5 


Future use 


ADJ-CH-INT 


Octet 6 


Future use 


Octet 7 


MAC-ID 



A.6.1 1 RLC-DFS-IVIT-INIT-REPORT-REQUEST-ACK encoding 
(OIVIT) 





8 1 7 1 6 


5 1 4 1 3 1 2 


1 


Octet 3 


^ 


Future use 


REP-INI 


Octet 4 


Future use 


Octet... 


Octet 7 









A.6.1 2 RLC-CHANGE-FREQUENCY encoding 





8 1 7 1 6 


5 


4 1 3 1 2 1 


1 


Octet 3 




Future use 


FIRST-MAC-FRAME 


Octet 4 


LAST-MAC FRAME 


Octet 5 


Octet 6 


FREQUENCY-INDEX 


Octet 7 


Future use 



A.6.1 3 RLC-UPLINK-PC-CALIBRATION encoding 





8 


7 


6 


5 1 4 


3 


1 2 1 


1 


Octet 3 




Future use 


PC-OFFSET 


Octet ... 


Future use 


Octet 7 
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A.6.14 RLC-MT-ALIVE-REQUEST encoding 





8 


7 


6 


5 1 4 


3 1 2 1 1 


Octet 3 




Future use 


NO-OF-MT-ALIVE- 
PROCEDURES 


Octet 4 


MT-ALIVE-INTERVAL 


Octet 5 


Octet 6 


Octet 7 


Future use 



A.6.15 RLC-MT-ALIVE-REQUEST-ACK encoding 





8 


7 


6 


5 1 4 


3 


2 1 1 


Octet 3 




Future use 


Octet 4 


Future use 


Octet 5 


Octet 6 


Octet 7 


MAC-ID 



A.6.16 RLC-IVIT-ALIVE encoding 





8 


7 


6 


5 1 4 


3 


2 1 1 


Octet 3 




Future use 


Octet 4 


Future use 


Octet 5 


Octet 6 


Octet 7 


MAC-ID 



A.6.17 RLC-IVIT-ALIVE-ACK encoding 

Empty PDU 





8 


7 


6 


5 4 


1 3 1 


2 


1 


Octet 3 




Future use 


Octet ... 


Future use 


Octet 7 



A.6.18 RLC-iVIT-ABSENCE encoding (OAP/OIVIT) 





8 1 7 


6 


5 1 4 1 3 


2 1 1 


Octet 3 


_ - - 






Future use 


Octet 4 


Future use 




MT-ABSENCE-TIME 




Octet 5 


Future use 


Octet 6 


Octet 7 


MAC-ID 
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A.6.19 RLC-MT-ABSENCE-ACK encoding (OAP/OMT) 



Empty PDU. 





8 


7 


6 


5 1 4 


1 3 1 


2 


1 1 


Octet 3 




Future use 


Octet ... 


Future use 


Octet 7 



A.6.20 RLC-SLEEP encoding (OIVIT) 





8 


7 1 6 


5 1 4 


1 3 


2 


1 


Octet 3 




Future use 


care-of-bc 


Octet 4 




Future use 




SLEEP-GROUP 1 


Octet 5 


Future use 


Octet 6 


Octet 7 


MAC-ID 



A.6.21 RLC-SLEEP-ACK encoding (OIVIT) 





8 


7 1 6 


5 4 3 2 


1 


Octet 3 




Future use 


care-of-bc 


Octet 4 




Future use 


1 SLEEP-GROUP 




Octet 5 


OFFSET 


Octet 6 


Octet 7 


Future use 



A.7 Transfer Syntax Tables for SCH DUCC messages 
A.7.1 RLC-DM-MODIFY-COMPLETE-ACK encoding (OAP/OMT) 





8 


7 


6 


5 1 4 


3 


2 1 1 


Octet 3 




Future use 


Octet 4 


MAC-ID 


Octet 5 


Future use 


Octet 6 


Octet 7 


MAC-ID 



A.7.2 RLC-DM-CONNECT-COMPLETE-ACK encoding 
(OAP/OMT) 





8 


7 


6 


5 1 4 


3 


2 1 


Octet 3 




Future use 


Octet 4 


MAC-ID 


Octet 5 


Future use 


Octet 6 


Octet 7 


MAC-ID 
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A.8 Transfer Syntax Tables for other RLC SCH 
messages 



A.8.1 RLC-NO-SUPPORT encoding 





8 1 7 1 6 1 5 1 4 1 


3 


2 


1 


Octet 3 




Future 
use 


SCH-LCH 


Octet 4 


Not-supported-PDU-type 


Octet 5 


Future use 


EXTENSION-TYPE 


Octet 6 


Future use 
Future use 


Octet 7 


MAC-ID (if Uplink) 
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Annex B (normative): 
Types 

The implementations shall follow the numbering (0, 1, ...) in the enumerated lists. 

Table B.I : Data description 



ADJACENT-CH-INTERFERENCE ::= ENUMERATED { 
channel-inteference-0 (0) } 


field size 2 bits. 


AGE-OF-MEASUREMENT 
::= INTEGER(0..4095) 


In request: The maximum age for the last BCH 

measurement. If the BCH on the requested frequency has 

been measured within this time for other reasons, 

e.g. handover, the MT is not required to perform the BCH 

decoding. Instead, the MT may use stored values of the 

BCH content and the RSS measured on the BCH. 

In report: Indicates the time since the measurement was 

performed. This is important if the AP polls the MT for 

measurement results. Age is the number of MAC frames 

since the measurement was finished. Age = means that 

the measurement was performed in the previous MAC 

frame. 

The accuracy ± 2 MAC frames is allowed for the value. The 

backoff value due to collisions in the RACH shall not be 

taken into account. 

12 bit field. 


ALLOCATION-TYPE ::= ENUMERATED { 
basic (0) 
fca (1) 
fsa (2) } 


3 bits. 

Fixed Capacity Agreement. 
Fixed Slot Allocation. 


AP-ID 

::= INTEGER (0 .. 1023) 


Access Point Identifier [5]. 
AP-ID value for future use. 
10 bit field. 


APT-ADDRESS-LENGTH 
::= INTEGER (0.. 10) 


4 bits field. 

Indicates the number of bits assigned for transceiver 

identification starting from the least significant bit of the AP 

ID. In case of single transceiver Aps the apt-address-length 

shall be set to zero. 

Values of apt-address-length greater than zero shall be 

indicated only, when the AP supports radio handover. In a 

single coverage area using Aps with identical net-id Vne 

apt-address-length shall be set to the same value in all Aps. 


AP-TOKEN-AUTH-ENCR::= SEOUENCE { 
token TOKEN 
authentication-encryption-list AUTHENTICATION- 
ENCRYPTION-LIST 

auth-encr-selected AUTH-ENCR-INFO } 




ARQ-DATA ::= SEQUENCE { 

arq-nr-of-retr INTEGER (0.. 15) 
arq-window-size WINDOW-SIZE } 


4 bit field. 
3 bit field. 


ARQ-DELAY 

::= INTEGER (0..3) 


ARO Delay Class. See [5]. 
3 bit field. 


AUTH-ENCR-INFO ::= SEQUENCE { 
auth-info AUTH-INFO 
encr-info ENCR-INFO} 




AUTHENTICATION-ENCRYPTION-LIST ::= SEQUENCE 

(SIZE(1..15))0F 

AUTH-ENCR-INFO 


The list is ordered by preference. The first item has the 
highest preference. 
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AUTH-INFO ::= ENUMERATED { 
no-authentication (0) 
pre-shared-l<ey-based (1) 
signature-based-512 (2) 
signature-based-768 (3) 
signature-based-1 024 (4)} 


4 bits field size. 


AUTH-RESP0NSE-PART1 ::= OCTET STRING 
(SIZE(16..32)) 


Only the values 16 and 32 are used. See CHALLENGE. 


AUTH-RESP0NSE-PART2 ::= OCTET STRING 
(SIZE(16..48)) 


Only the values 16, 32 and 48 are used. See CHALLENGE. 


BCH-FOUND ::= ENUMERATED { 
bcli-not-found (0) 
bcli-found (1)} 


Field size 1 bit. 


BCH-RX-LEVEL 

::= INTEGER{0..63) 


Measured signal strength of the BCH on frequency f. It is 
an index to a signal strength [4]. 
6 bit field. 


BROAD-WINDOW ::= ENUMERATED { 
bw-size32 (0) 
bw-size64 (1) 
bw-size128 (2) 
bw-size256 (3)} 


2 bits. Window size for repeated broadcast PDUs, see [5]. 


CARE-OF-BROADCAST ::= ENUMERATED { 
dont-care-of-broadcast (0) 
care-of-broadcast (1)} 


Field size 1 bit. 


CC-HO-CAP ::= ENUMERATED { 
cc-ho-not-supported (0) 
cc-ho-supported (1)} 


Field size 1 bit. 


CHALLENGE ::= OCTET STRING (SIZE (16)) 


Used in the authentication procedure. 

A random number sent to the other party 

that calculates a response according to the authentication 

procedure, with the challenge as an input. 


CL-ATTRIBUTES ::= OCTET STRING (SIZE(0..44)) 


The convergence layers exchange information between 
themselves, transparent to RLC. 






CL-COMMON-ATTR ::= OCTET STRING (SIZE(0..31)) 




CL-CONN-ATTR ::= OCTET STRING (SIZE(0..31)) 




CL-DATA ::= SEOUENCE { 
cl-id CL-ID 
cl-attributes CL-ATTRIBUTES} 




CL-ID ::= ENUMERATED! 

atm (0), - 'OOOOOOOO'B cell based CL, ATM service, 

ethernet (32), -'00100000'B packet based CL, ethernet 

service, 

ieee1394 (33) - '001 00001 'B IEEE 1394 [9] CL 

1 


8 bit field size. 


CL-VERSION 

::= INTEGER(0..255) 


Both MT and AP send their own version in Link Capability 

procedure. 

8 bit field. 


cMAX-DESCR-LIST INTEGER ::= 16 




cMAX-ID-LIST INTEGER ::= 16 




CODER-TYPE ::= ENUMERATED { 
reed-solomon-21 6-200 (0)} 


8.2.1.1.1 Field size: 2 bits 
Reed-Solomon code. 


COMMON-KEY ::= CHOICE { 
no-encr [0] NULL 

des-encr [1] OCTET STRING(SIZE(8)) 
tripledes [2] OCTET STRING(SIZE(24))} 


A key used to encrypt multicast and/or broadcast traffic. 


C-U-G ::= ENUMERATED { 
open-user-group (0) 
closed-user-group (1)} 


Open group: All MTs allowed to attempt association. 
Closed group: Only MTs with a matching network 
operator identifier allowed to attempt 
association. 
1 bitfield. 


CYCLIC-PREFIX ::= ENUMERATED { 
t400ns (0) 
tSOOns (1)} 


800 ns in mandatory, 400 ns is optional [4]. 
1 bitfield. 


DH-PUBLIC-VALUE-HALF ::= OCTET STRING (SIZE(48)) 


DH = Diffie-Hellman. Used to create encryption key. 
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DIRECTION ::= ENUMERATED { 
simplex-forward (0) 
simplex-backward (1), 
duplex (2), 
duplex-symetric (3)} 


2 bit field. 

Simplex connection, forward direction. 

Simplex connection, backward direction. 

Duplex connection. 

Duplex-symetric - the same data used for both directions. 


DIRECT-MODE-CAP ::= ENUMERATED { 
no-dm-capabilities (0) 
dm-capabilities (1)} 


1 bitfield size. 


DISASSOCIATION-CAUSE ::= ENUMERATED { 
unknown-dis-cause (0) 
user-disassociation (1) 
operator-disassociation (2) 
low-qos-dis (3) 
traffic-overload-dis (4) 
authentication-failed (5) 
mt-powerdown (6) 
ap-powerdown (7) 
mismatched-resources (8)} 


4 bits. A "user" can be any "user" of the system, both at the 
MT and the AP. 


DIL-POWER-CONTROL ::= ENUMERATED { 
dil-fixed-pc (0) 
dil-dynamic-pc (1)} 


- 2 bits. 

- Fixed power = Max power - 3 dB. 

- Dynamic dil power control as defined in HE. 


DLC-ATTRIBUTES ::= OCTET STRING {SIZE(0..44)) 


The DLC layers exchange information between themselves, 
transparent to RLC. 


DLC-ATTR-PR ::= ENUMERATED { 
dic-attr-not-present (0) 
dic-attr-present (1)} 


Field size 1 bit. 


DLCC-DESCR ::= SEQUENCE { 
dicc-id DLCC-ID 
cl-conn-attr CL-CONN-AI 1 K} 




DLCC-DESCR-LIST ::= SEQUENCE (SIZE(1..16)) OF DLCC- 
DESCR 


The maximum number of elements is limited by the 
LCH-PDU length and the number of other parameters used 
in the same RLC PDU. 


DLCC-ID 

::= INTEGER (0 .. 63) 


DLC Connection Identifier [5]. 
6 bit field. 


DLCC-ID-LIST ::= SEQUENCE 
(SIZE(1..cMAX-ID-LIST)) OF DLCC-ID 


The maximum number of elements is limited by the 
LCH-PDU length and the number of other parameters used 
in the same RLC PDU. 


DM-ATTRIBUTES ::= SEQUENCE { 
dil-power-control DIL-POWER-CONTROL 
tx-arq-win-size WINDOW-SIZE 
rx-arq-win-size WINDOW-SIZE } 


A minimum ARQ window size shall be negotiated here. The 
DM-attribute is used by home extension to negotiate some 
specific DM parameters. 


DM-USE-COMMON-KEY ::= ENUMERATED { 
no-common-key (0) 
use-common-key (1)} 


1 bit. 


DUC-DESCR ::= SEQUENCE { 

direction [0] DIRECTION 

dIcc-id [1] DLCC-ID 

cl-conn-attr [2] CL-CONN-ATTR 

forward-descr [3] DUC-DIRECTION-DESCR-FW 
OPTIONAL 

backward-descr [4] DUC-DIRECTION-DESCR-BW 
OPTIONAL} 


Forward-descr shaW be used, when direction indicates 
simplex_forward, dupiexox duplex_symmetric. 
bacl<ward-descr shaW used, when direction indicates 
simplex_bacl<ward, dupiex. 


DUC-DESCR-LIST ::= SEQUENCE 
(SIZE{1..cMAX-DESCR-LIST)) OF DUC-DESCR 


The maximum number of elements is limited by the 
LCH-PDU length and the number of other parameters used 
in the same RLC PDU. 


DUC-DIRECTION-DESCR ::= SEQUENCE { 
allocation-type [0] ALLOCATION-TYPE 
cyclic-prefix [1] CYCLIC-PREFIX 
fee-used [2] FEC-USED 
ec-mode [3] EC-MODE 
arq-data [4] ARQ-DATA OPTIONAL 
fee [5] FEC-DESCR OPTIONAL 
fca-descr [6] FCA-DESCR OPTIONAL 
fsa-descr [7] FSA-DESCR OPTIONAL} 


Fee shall be present, wlien fee-used is set. arq-data shall 
be present, when ec-mode is set to acknowledged-nnode. 
fca-descr shaW be present, when allocation-type indicates 
fca, fsa-descr shaW be present, ivften allocation-type 
indicates fsa. 


DUC-DIRECTION-DESCR-BW 
::= DUC-DIRECTION-DESCR 


DUC description to be used for the backward direction. 
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DUC-DIRECTION-DESCR-FW 
::= DUC-DIRECTION-DESCR 


DUC description to be used for the forward direction. 


DUC-ESTABLISHED ::= ENUMERATED { 
no-duc-established (0) 
dues-established (1)} 


Field size 1 bit. 

Indicates, if the MT maintains on-going unicast DUCs. This 
parameter shall be considered by the target AP during 
network handover when re-establishing on-going DUCs. 


DUC-EXT-IND ::= ENUMERATED { 
no-duc-ext (0) 
duc-ext (1)} 


Field size 1 bit. 


DUTY-CYCLE ::= ENUMERATED { 

fiveper (0) 
tenper (1) 
twentyper (2) 
thirtyper (3) 
fortyper (4) 
sixtyper (5) 
eightyper (6) 
hundredper (7)} 


Percent of the MAC frame that the MT can use for uplink 

transmission. Upper limit, which AP may take into account. 

5% 

10% 

20% 

30% 

40% 

60% 

80% 

1 00 % 

3 bit field 


EC-MODE ::= ENUMERATED { 
arq-not-used (0) 
arq-used (1) 
repetition-mode (2)} 


Field size 2 bits. 


ENCR-INFO ::= ENUMERATED { 
no-encryption (0) 
des (1) 
tripleDES (2)} 


4 bits field size. 


ENCRYPTION-ALGORITHM-PROPOSAL ::= SEQUENCE 
(SIZE{1..15))0FENCR-INFQ 


The list is ordered by preference. The first item has the 
highest preference. 


ERRQR-CORR-MODE ::= ENUMERATED { 
repetition-mode (0) 
unacknowledged-mode (1)} 


1 bitfield size, used in CL-BROADCAST-JOIN-ACK 
message. 


EXTENSION-TYPE ::= ENUMERATED { 
basic-ric (0) 
home-extension (1) 
business-extension (2) } 


3 bits field size. This field is set to every RLC PDU. The 
usage of the field allows re-usage of the RLC PDU TYPE 
field for different extensions. This field shall be encoded to 
to indicate the PDUs defined in the present document. 


FCA-DESCR ::= SEQUENCE { 

sch-per-nb-frames INTEGER (1 ..1 5) 
Ich-per-nb-frames INTEGER (1 ..1 5) 
nb-of-sch INTEGER {0..1) 
phy-mode-sch PHY-MODE-SCH 
phy-mode-lch PHY-MODE-LCH 
nb-of-lch INTEGER (0..255) 
min-nb-of-lch INTEGER {0..255)} 


Nb = number. 
4 bit field. 
4 bit field. 
1 bitfield. 

8 bit field. 
8 bit field. 


FEC-DESCR ::= SEQUENCE { 

coder-type CODER-TYPE, 
interleaver-type INTERLEAVER-TYPE} 




FEC-USED ::= ENUMERATED { 
fec-not-used (0) 
fee-used (1)} 


Field size 1 bit. 


FIRST-MAC-FRAME 
::=INTEGER(0..15) 


RLC_CHANGE_FREQUENCY: Index to the first frame 

transmitted on new frequency. 

RLC_AP_ABSENCE: The first frame where AP will transmit 

again after AP absence. 

The reference for the number is the MAC frame where the 

AP stops transmitting. denotes the MAC frame 

immediately after the MAC frame where the AP stops 

transmitting. 

4 bit field. 
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FORCE-HANDOVER-CAUSE ::= ENUMERATED { 
unspec-fho-cause (0) 
traffic-overload (1) 
bad-link (2) 
operator-action (3) 
cell-closure (4) 
mt-behaviour (5) 
qos-not-achieved (6)} 


3 bits field size. 


FRAME-COUNTER 
::= INTEGER (0.. 15) 


4-bit Frame counter. 


FRAME-NUM 

::= INTEGER (0..65535) 


Integer value with unit FRAMES (1 6 bit). 


FREQUENCY-BAND ::= ENUMERATED { 
lower-band-only (0) 
upper-band-only (1) 
lower-and-upper-band (2)} 


Field size 2 bits. A node declares which frequency band 
that it can use. Low band: 5 180 MHz to 5 320 MHz. High 
band: 5 500 MHz to 5 700 MHz. 


FREQUENCY-INDEX ::= INTEGER (1..255) 


Field size 8 bits. The value points to the nominal carrier, 
see TS 101 475 [4]. 


FSA-DESCR ::= SEQUENCE { 

phy-mode-lch PHY-MODE-LCH 
nb-of-lch INTEGER {0..255), -8 bit field 
min-nb-of-lch INTEGER {0..255), -8 bit field 
start-pointer START-POINTER, 
start-mac-frame START-MAC-FRAME } 


Fixed Slot Allocation (FSA) may be used in any EC mode 
and with or without FEC. When using unacknowledged 
mode, a MT does not have to decode the FCCH once the 
connection is set up. When using acknowledged mode, a 
MT shall decode the FCCH, because SCHs for 
acknowledgements and discards are granted in basic 
allocation mode. Only LCHs can be allocated with FSA. 

In case of an FSA-RG the AP/CC shall set the 
min-nb-of-lch to the same value as nb-of-lch. 


GROUP-MAC-ID 

::= MAC-ID (224..255) 


MAC ID used for a multicast group. The value 255 shall be 
used for overflow multicast traffic, that is, when the values 
224 to 254 are used up. 


HANDOVER-CAUSE ::= ENUMERATED { 
unspec-ho-cause (0) 
link-quality (1) 
traffic-related (2) 
network-related (3) } 


Field size 4 bits. 

Defines the reason why an MT performs a handover. 


IDENTIFIER-FORMAT ::= ENUMERATED { 
network-id-available (0) 
network-id-unavailable (1)} 


3 bits field size. 

Two values are used at present. One value for network 
operator available and the other value for no network 
operator available. 


IDENTIFYER::= CHOICE! 
empty NULL 
full OP-ID} 




INFO-COUNT ::= INTEGER {0..7) 




INFO-TYPE ::= ENUMERATED { 
new-info (0), 
retrans-info (1)} 


Field size 1 bit. 


INTERLEAVER-TYPE ::= ENUMERATED { 
no-interleaver (0) 
three-branch-conv (1)} 


Field size 2 bits. 


KEEP-CONNECTIONS ::= ENUMERATED { 
donot-keep-conn (0) 
keep-connections (1)} 


Field size 1 bit. 


KEY-ID 

::= INTEGER (0..255) 


Identifier for a common encryption key. A key can be used 
in different places and to save resources a short identifier is 
used instead of the key itself. 
8 bit field. 


LAST-MAC-FRAME 

::= INTEGER(0..65535) 


16-bit field size. 

RLC_CHANGE_FREQUENCY: Index to the last 
transmitted frame on old frequency 
RLC_AP_ABSENCE: The last frame that the MT transmits 
at before AP Absence. 

Reference is the MAC frame in which the message from AP 
is received by the MT. The value shall mean the first MAC 
frame after the one in which the message was received by 
the MT. 
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LAST-OWN-BCH-RX-LEVEL 
::= BCH-RX-LEVEL 


Measurement result: RSS on the used frequency BCH. 


MAC-ID 

::= INTEGER (0 .. 255) 


8 bits Identifier used in communication between MT and 
AP/CC or another MT [5]. 


MAC-IDO ::= MAC-ID(O) 


A subtype of MAC-ID. A fixed value used for upstream 
communication before an MT has got a MAC-ID of its own 
(RLC MAC ID ASSIGN and 
RLC RBCH ASSOCIATION REQUEST). 


MAC-ID-AND-CL-DATA ::= SEQUENCE { 
mac-id-choice IVIAC-ID-CHOICE 
cl-data CL-DATA } 




MAC-ID-AND-CL-DATA-LIST ::= SEQUENCE (SIZE(1..7)) OF 
MAC-ID-AND-CL-DATA 




MAC-ID-CHQICE ::= CHOICE { 

group-mac-id [0] GROUP-MAC-ID, 
unicast-mac-id [1] MAC-ID, 
broadcast-mac-id [2] MAC-ID} 




MAGIC 

::= INTEGER (0..65535) 


Random number, 16 bits. The same magic number shall be 
kept during the retransmissions of the messages that use it. 
It is used as a temporary identifier until MT has got its own 
MAC-ID. 


MAXIMUM-AGE-OF-BCH-MEASUREMENT 
::= AGE-OF-MEASUREMENT 


Sort: Number of MAC frames. 


MD5-0N-KEY ::= OCTET STRING (SIZE(16)) 


The MD5 algorithm operating on l<ey. 


MD5-0N-N0NCE ::= OCTET STRING (SIZE(16)) 


The MD5 algorithm operating on nonce. 


MEASUREMENT-TYPE ::= ENUMERATED { 
type-a (0) 
type-b(1) 
type-c (2) 
type-u (3)} 


field size 2 bits. 

The measurement types a, b, c are described in 
MEASUREMENT_REQUEST_MESSAGEs. Measurement 
type u (undefined) means that the MT has performed a 
measurement on the specified frequency, which does not 
follow any of the predefined measurement types. In this 
case, it is up to the AP to request necessary measurements 
from the MT. The adjacent channel flag indicates if the 
measurement concerns adjacent channel interference or 
not. 


MEASUREMENT-WINDOW 
::= INTEGER (0..63) 


6 bitfield size. 

On other frequency measurement window defines how 
many MAC-frames time units shall be spent on 
measurements. If the measurement type is percentile this 
time is spent on RSS statistics measurements. If 
measurement type is short the measurement window is 5 
frames and the RSS from the strongest BCH obtained is 
reported together with the BCH-content. If the type is 
complete 5 frames of the window is used for BCH-synch 
and decode and the rest spent on RSS statistics 
measurements. 

On used frequency measurement-window gives a coarse 
description of the measurement interval and the final 
description is given by the AP-absence message or the 
FCH-empty-part of frame information. 


MORE-AUTH ::= ENUMERATED { 
more-auth-pdu (1) 
last-auth-pdu (0)} 


field size 1 bit. Indicates whether more PDUs are to follow 
or not. Used when authentication information is longer than 
what can be contained in one PDU. 


MORE-JOINS ::= ENUMERATED { 
no-more-joins (0) 
more-joins (1)} 


Field size 1 bit. 


MT-ABSENCE-TIME 
::= INTEGER (0..63) 


Defines the absence period of the MT in MAC frames. 
6 bit field. 


MT-ALIVE-INTERVAL 

::= INTEGER (0.. 1677215) 


Period (in number of frames) that MT Alive procedure is 
commanded to be triggered in. 
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MT-AUTH-CONTENT ::= CHOICE {; 

ieee [0] OCTET STRING (SIZE(6)) 
ext-ieee [1] OCTET STRING (SIZE(8)) 
net-acc-id [2] OCTET STRING (SIZE(1 ..46)) 
dist-name [3] OCTET STRING (SIZE(1 ..46)) 
compressed [4] OCTET STRING {SIZE{1 6)), 
generic [5] OCTET STRING (SIZE(1 ..46))} 

} 


Type of MT authentication identifier. 

The compressed type can be used if the available 
authentication key identifier is so long that it is not possible 
to carry in the defined RLC messages. The compressed 
authentication key identifier is calculated as follows: 
compressed-authentication-key-identifier = MD5 
(available_authentication_key_identifier). 

The generic type is a non-structured octet string. 


MT-AUTH-ID-TYPE ::= ENUMERATED { 

ieee (0) 

ext-ieee (1) 

net-acc-id (2) 

dist-name (3) 

compressed (4) 

generic (5) } 
} 


Type of MT authentication identifier. 
4 bit field. 

The compressed type can be used if the available 
authentication key identifier is so long that it is not possible 
to carry in the defined RLC messages. The compressed 
authentication key identifier is calculated as follows: 
compressed-authentication-key-identifier = 
MD5(available_authentication_key_identifier). 

The generic type is a non-structured octet string. 


MT-TOKEN-AUTH-ENCR ::= OCTET STRING (SIZE(16)) 


The MD5 algorithm operating on token. 


NET-ID 

::= INTEGER (0 .. 1023) 


10 bit Identifier for network on DLC- level [5]. Value is for 
future use. Certain other numbers are reserved for the 
standardized use by public network operators. 


NETW-OP-ID-GLOBAL ::= lASString (SIZE(0..31)) 


ASCII string of up to 31 characters, that is up to 31 octets. 
This part is globally unique. 


NETW-OP-ID-LOCAL ::= 
lASString (SIZE(0..31)) 


ASCII string of up to 31 bytes, that is 31 characters/digits. 


NETWORK-OPERATOR-ID ::= SEQUENCE { 
identifier-format IDENTIFIER-FORMAT, 
identifyer IDENTIFYER) 




NONCE ::= OCTET STRING (SIZE{16)) 


A random value used during authentication. 


NO-OF-MT-ALIVE-PROCEDURES ::= INTEGER (0..4) 


A 3 bit integer stating how many times the MT alive 
procedure shall fail before disassociation takes place. Sent 
from AP to MT. 


NUMBER-OF-SAMPLES 
::=INTEGER(0.. 16383) 


14 bitfield size. 

In percentile and complete report: The measurement 
length, given in number of 8 us samples taken in RSS 
statistics measurements. 


NUMBER-TEST-LCH ::= INTEGER (1..5) 


3 bit field size 

number of test LCHs per MAC frame 


OMNI-ANTENNA-USED ::= ENUMERATED { 
omni-antenna-not-used (0) 
omni-antenna-used (1)} 


1 bitfield size. 

Omni antenna definition: If the maximum antenna gain, 

measured in the horizontal plane, is 6 dB greater than the 

average antenna gain in the horizontal plane, the antenna 

is considered as a directional antenna. Otherwise the 

antenna is considered as non-directional. 

Note: the calculation of the average gain should be 

performed in linear scale, not dB scale. 


OP-ID ::= SEQUENCE! 

unique-length UNIQUE-LENGTH 
c-u-g C-U-G 
netw-op-id-local NETW-OP-ID-LOCAL 
netw-op-id-global NETW-OP-ID-GLOBAL } 




PC-OFFSET ::= ENUMERATED { 
future-useO (0) 
plus6db (1) 
plus3db (2) 
minusSdb (3) 
minus6db (4) 
reset-tx-level (7)} 


3 bit field size. See TS 1 01 475 [4]. 


PDU-TYPE-CHOICE ::= CHOICE ( 
Ich RLC-LCH-PDU-TYPE 
schRLC-SCH-PDU-TYPE } 
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PHY-MODE-LCH ::= ENUMERATED { 
nophy-mode-proposal (0) 
cpBPSK1-2 (1) 
cpBPSK3-4 (2) 
cpQPSK1-2 (3) 
cpQPSK1-3 (4) 
cp16QAM9-16 (5) 
cp16QAM3-4 (6) 
cp64QAM3-4 (7)} 


4 bits field size, 
no proposal. 
BPSK, code rate 1/2. 
BPSK, code rate 3/4. 
QPSK, code rate 1/2. 
QPSK, code rate 3/4. 
16QAM, coderate9/16. 
1 6QAM, code rate 3/4. 
64QAM, code rate 3/4. 


PHY-MODE-SCH ::= ENUMERATED { 
nophy-mode-propos (0) 
CBPSK1-2 (1) 
CBPSK3-4 (2) 
cQPSKI-2 (3) 
cQPSKI-3 (4) 
C16QAM9-16 (5) 
C16QAM3-4 (6) 
C64QAM3-4 (7)} 


3 bits field size, 
no proposal. 
BPSK, code rate 1/2. 
BPSK, code rate 3/4. 
QPSK, code rate 1/2. 
QPSK, code rate 3/4. 
16QAM, coderate9/16. 
1 6QAM, code rate 3/4. 
64QAM, code rate 3/4. 


PROFILE-VID ::= SEQUENCE { 
profile-id PROFILE-ID, 
profile version PROFILE-VERSION} 




PROFILE-VID-LIST ::= SEQUENCE (SIZE (0..5)) OF 
PROFILE-VID 




PROFILE-ID::= INTEGER (0..31) 


5 bit profile id administered by BRAN. Profiles and values to 
be defined. 


PROFILE-VERSION ::= INTEGER (0..31) 


5 bit version per profile. Administered by BRAN. 


RELEASE-CAUSE ::= ENUMERATED { 
unknown-release-cause (0) 
normal-release (1) 
low-qos (2) 
timed-out (3) 
lack-of-resources (4) 
network-operator-release (5)} 


field size 4 bits. 


REPETITION-COUNTER ::= INTEGER (0..4095) 


Gives the number, the MAC Frame Counter value repeats 
in BCCH after the reception of the start-mac-frame 
parameter (1 repetition corresponds to 16 MAC frames). 
The frame, in which the frame counter of the BCCH takes 
the value frame-count ^or the first time after reception of the 
start-mac-frame parameter, corresponds to a 
repetition-counter va\ue of 0. 
12 bit field size. 


REPORTING-INITIALIZED ::= ENUMERATED { 
reporting-not-initialized (0), 
reporting-initialized (1)} 


Field size 1 bit. 


RETURN-FLAG ::= ENUMERATED { 
return-not-allowed (0), 
return-allowed (1)} 


Field size 1 bit. 


RLC-VERSIQN 

::= INTEGER (0..255) 


Both MT and AP send their own version in Link Capability 
procedure. The present document is RLC version 1 . 
8 bit field. 


RSS-INDEX ::= ENUMERATED { 
rss-minimum (0) 
rss-5-percent (1) 
rss-1 0-percent (2) 
rss-20-percent (3) 
rss-30-percent (4) 
rss-40-percent (5) 
rss-50-percent (6) 
rss-60-percent (7) 
rss-70-percent (8) 
rss-80-percent (9) 
rss-90-percent (10) 
rss-95-percent (11) 
rss-maximum (12)} 


field size 4 bits. 

Percentage of the maximum value. 
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RSS-INDEX-LIST ::= SEQUENCE (SIZE (5)) OF RSS-INDEX 




RSS-STATISTICS 
::= INTEGER(0..63) 


Measurement result: RSS statistics on frequency f. Number 
of samples in the different percentiles, minimum or 
maximum. 
6 bit field. 


RSS-STATISTICS-LIST ::= SEQUENCE (SIZE (5)) QF 
RSS-STATISTICS 




RSS- VALUE 

::= INTEGER(0..63) 


6 bits. When used in the Link Capability messages, it is the 
latest Received-Signal-Strength value measured by the MT 
before the signal was sent. When used in the 
RLC LINK CAPABILITY ACK or 

RLC_HANDOVER_LINK_CAPABILITY_ACK message, it is 
the same value that was sent in the 

RLC_LINK_CAPABILITY message. It is an index to an RSS 
value given in dBm, see TS 101 475 [4]. 


SCH-LCH ::= ENUMERATED { 
sch (0) 
Ich (1)} 


1 bitfield size. 


SECTQR-ID 

::= INTEGER (0..7) 


3 bits field size. 


SEND-NW-TQKEN ::= ENUMERATED { 
dont-send-nw-token (0) 
send-nw-token (1)} 


1 bitfield size. 


SLEEP-GRQUP 

::= INTEGER (0.. 15) 


Sleeptime = 2SI-EEP-GROUP (4 git). The value means, 
that no sleeping is allowed. 


START-AUTHENTICATION ::= ENUMERATED { 
dont-start-auth (0) 
start-auth (1)} 


1 bitfield size. 


START-DUC-SET-UP ::= ENUMERATED { 
donot-start-setup (0) 
start-setup (1)} 


1 bitfield size. 


START-ENCRYPTION ::= ENUMERATED { 
dont-start-encr (0) 
start-encr (1)} 


1 bitfield size. 


START-INFQ-TRANSFER ::= ENUMERATED { 
dont-start-info-transfer (0) 
start-info-transfer (1)} 


1 bit field size. 


START-MAC-FRAME ::= SEQUENCE { 

repetition-counter REPETITION-COUNTER 
frame-count FRAME-COUNTER} 


Gives the exact MAC Frame to start FSA. frame-count 
gives the frame counter value in the BCCH of the starting 
MAC frame of FSA. 


START-OF-MEASUREMENT 
::=INTEGER(2..15) 


The start of the measurement Interval is given in number of 
MAC frames. The starting point for counting the 
start-of-measurement shall be counted from the frame the 
start-of-measurement parameXer was received (number 0). 
The usage of the parameter is described in the DPS 
clauses. 
4 bit field. 


START-POINTER :;= INTEGER (0..8191) 


Pointer to the position of the Fixed Slot Allocation in the 
MAC Frame. 

Same meaning and coding as for Resource Grants, 
13 bitfield size. 


SUPPORTED64QAM ::= ENUMERATED { 
support64QAM (1) 
no-support64QAM (0) } 


Field size 1 bit. 


SUPPORTED-FCA ::= ENUMERATED { 
support-fca (1) 
no-support-fca (0)} 


Field size 1 bit. 


SUPPORTED-FSA ::= ENUMERATED { 
support-fsa (1) 
no-support-fsa (0)} 


Field size 1 bit. 


TEST-LOOP-BACK-DELAY ::= INTEGER (1..15) 


4 bits 

loop back delay in number of MAC frames (1 corresponds 

to loop back received test data in the next MAC frame) 
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TEST-MODE ::= SEQUENCE { 

test-mode-type TEST-MODE-TYPE, 
phy-mode-lch PHY-MODE-LCH, 
test-loop-back-delay TEST-LOOP-BACK-DELAY, 
test-repeat-delay TEST-REPEAT-DELAY, 
number-test-lch NUMBER-TEST-LCH} 


4 bits field size 
4 bits field size 
4 bits field size 
4 bits field size 
3 bits 


TEST-MODE-DLCC-FWBW-DESCR ::= DLCC-ID 




TEST-MODE-DUC-FWBW-DESCR ::= SEQUENCE { 
direction DIRECTION, 
dicc-id DLCC-ID, 
test-mode-fwbw-descr TEST-MODE-FWBW-DESCR } 




TEST-MODE-FWBW-DESCR ::= DUC-DIRECTION-DESCR 




TEST-MODE-TYPE ::= ENUMERATED { 
transm-cod-bypass-zeros (0), 
transm-cod-bypass-ones (1), 
transm-cod-bypass-zeroones-bitw (2), 
transm-cod-bypass-zeroones-hexw (3), 
transm-coding-zeros (4), 
transm-coding-ones (5), 
transm-coding-zeroones-bitw (6), 
transm-coding-zeroones-hexw (7), 
loop-back-a (8), 
loop-back-b (9), 
transm-coding-prbs-9 (10), 
transm-cod-bypass-prbs-9 (11),} 


4 bits field size 

bit pattern: 0000 0000 0000 ...., without encoding 

bit pattern: 1111 1111 1111 ...., without encoding 

bit pattern: 0101 0101 0101 ...., without encoding 

bit pattern: 0000 1111 0000 ...., without encoding 

bit pattern: 0000 0000 0000 ...., with encoding 

bit pattern: 1111 1111 1111 ...., with encoding 

bit pattern: 0101 0101 0101 ...., with encoding 

bit pattern: 0000 1111 0000 ...., with encoding 

loop back A without de-/encoding 

loop back B including de-/encoding 

pseudo-random bit sequence PRBS-9, with encoding 

pseudo-random bit sequence PRBS-9, without encoding 


TEST-REPEAT-DELAY ::= INTEGER (1..15) 


4 bits 

delay in number of MAC frames to be ready to receive 
loop back test data again (1 corresponds to receive loop 
back data in the next MAC frame again) 


TIME-GAP-ACH-UPLINK 
::= INTEGER (0..7) 


The minimum time, in [is, between the end of the ACH and 
the first uplink transmission of each individual MT [5]. 
= 0, 1 =16, 2 = 32, 3 = 64, 4= 128,5 = 256, 
6 = 512,7 = 1 024. 
3 bit field. 


TOKEN ::= OCTET STRING (SIZE(16)) 


Used for network handover authentication. 


TRAFFIC-LOAD ::= ENUMERATED { 
notusedO (0) 
notused7 (7)} 


3 bits, not used in phase 1 . 


TX-LEVEL ::= ENUMERATED { 
dbm30 (15) 
dbm27 (14) 
dbm24 (13) 
dbm21 (12) 
dbm18 (11) 
dbmIS (10) 
dbm12 (9) 
dbm9 (8) 
dbm6 (7) 
dbm3 (6) 
dbmO (5) 
dbmm3 (4) 
dbmmS (3) 
dbmm9 (2) 
dbmm12 (1) 
dbmmIS (0)} 


4 bits. The AP transmit level that the MT has read from the 
field in the BCH of the measured AP. 
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UNIQUE-LENGTH 
::=INTEGER(0..31) 


The unique length field indicates the length of the globally 
unique part of the network operator identifier in bytes. 
5 bit field. 


USE-OMNI-ANTENNA ::= ENUMERATED { 
dont-use-omni-antenna (0) 
use-omni-antenna (1)} 


1 bitfield size. 


WINDOW-SIZE ::= ENUMERATED { 
arq-not-used (0) 
w-size32 (1) 
w-size64 (2) 
w-size128 (3) 
w-size256 (4) 
w-size512 (5)} 


3 bits. See TS 101 761-1 [5]. 
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Annex C (normative): 
RLC TIMERS 

T_short = 16 frames = 32 ms. 

T_medium = 8 x T_short = 128 frames = 256 ms. 

T_long = 8 X T_medium = 1 024 frames = 2 048 ms. 

T_encryption = 2 x T_long = 2 048 frames = 4 096 ms. 

T_dfs = start-of-measurement + measurement-window + 5 frames. 

Table C.I : MT Timers 



MT (testing AP) 


Value 


T rbch association req 


T short 


T mac id assign 


T short 


T link capability 


T short 


T key exchange mt 


T encryption 


T authentication 


T medium 


T authentication ap 


T long 


T authentication-ap 


T medium 


T dm common key distr ack 


T short 


T info 


T short 


T groupjoin 


T short 


T group leave 


T short 


T cl broadcastjoin 


T short 


T cl broadcast leave 


T short 


T disassociation mt 


T short 


T connect ack 


T short 


T setup mt 


T short 


T connect mt 


T short 


T release mt 


T short 


T modify req mt 


T medium 


T modify mt 


T medium 


T reset mt 


T short 


T dfs mt init report 


T short 


T sector handover req 


T short 


T handover request 


T short 


T handover notify 


256 frames 


T nw signalling handover 


T medium 


T force handover return 


256 frames 


T sleep request 


T short 


T mt alive 


T short 


T dm setup mt 


T short 


T dm connect mt 


T short 


T dm connect cmpt mt 


T medium 


T relay setup mt 


T medium 


T dm release mt 


T medium 


T relay release mt 


T medium 


T dm modify req mt 


T short 


T dm modify mt 


T short 


T dm modify cmpt mt 


T medium 


T relay modify mt 


T medium 


T dm reset mt 


T medium 


T test mode setup mt 


T short 


T test mode connect mt 


T short 


T_prepare_test_mode_mt 


T short 
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Table C.2: AP Timers 



AP (testing MT) 


Value 


T mac id assign acl< 


T short 


T link capability ack 


T short 


T key exchange ap 


T encryption 


T authentication mt 


T long 


T authentication ack 


T long 


T dm common key distr 


T short 


T nw signalling handover ack 


T short 


T info ack 


T short 


T disassociation ap 


T short 


T unicast key refresh 


T medium 


T common key refresh 


T medium 


T connect ap 


T short 


T setup ap 


T short 


T release ap 


T short 


T modify ap 


T medium 


T modify req ap 


T medium 


T reset ap 


T short 


T force handover 


T short 


T force handover return 


256 frames 


T handover association 


T short 


T handover link capability ack 


T short 


T handover notify 


256 frames 


T nw signalling handover ack 


T short 


T nw handover complete 


T short 


T ho info distribution 


T short 


T mt alive request 


T short 


T mt absence 


T short 


T dm setup ap 


T short 


T dm connect ap 


T short 


T dm connect cmpt ap 


T short 


T dm release ap 


T short 


T dm modify req ap 


T short 


T dm modify ap 


T short 


T dm modify cmpt ap 


T short 


T dm reset ap 


T short 


T test mode setup ap 


T short 


T test mode connect ap 


T short 


T_prepare_test_mode_ap 


T short 
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Annex D (normative): 

SDL specification of the RLC protocol 

The present document has been produced using Specification and Description Language - SDL and Abstract Syntax 
Notation No 1 - ASN.L 

The archive containing all available formats of the specification is ts_10176102v010301p0.zip. 



D.1 The SDL Graphical form (SDL/GR) 

The graphical form of SDL specification is available in tool specific format. All relevant files are contained in the 
archive rlcsdl_v04r00.zip included in the archive ts_10176102v010301p0.zip. The achieve also contains the ASN.l 
files that are part of the model. 



D.2 The SDL Textual format (SDL/PR) 

The SDL textual format is tool independent. It preserves the meaning of the specification but does not preserve the 
graphical layout. SDL/PR is available in the archive rlcsdl_v04r00pr.zip included in the archive 
ts_10176102v010301p0.zip. 



D.3 The SDL Common Interchange format (SDL/CIF) 

The SDL Common Interchange format is tool independent. It preserves the meaning of the specification and the 
graphical layout. SDL/CIF is available in the file archive rlcsdl_v04r00cif.zip included in the archive 
ts_10176102v010301p0.zip. 



D.4 The ASN.1 files 

The ASN.l files that are specifying the abstract message structure are included with the SDL/GR but are also available 
in the archive rlcsdl_v04r02asn.zip included in the archive ts_10176102v010301p0.zip. 



D.5 The PDF format 

The SDL specification including the ASN.l part is available for viewing/printing in PDF format in the file 
rlcsdl_v04r00.pdf in ts_l 1 76 1 02v0 1 030 IpO.zip. 
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